Skip to content
This repository was archived by the owner on Jun 2, 2026. It is now read-only.

security-scanning.md

Latest commit

 

History

History
113 lines (77 loc) · 3.43 KB

security-scanning.md

File metadata and controls

113 lines (77 loc) · 3.43 KB
Raw

Manual Security Scanning

This project keeps dependency vulnerability scanning as a manual developer workflow instead of a required CI gate. The goal is to make security checks available without making normal test/build CI unstable because of changing third-party advisory databases.

These scans check third-party dependencies. They do not replace application-level security tests such as JWT, authentication, RBAC, or protected endpoint tests.

What This Checks

Dependency vulnerability scanners compare the project dependency graph against public vulnerability databases.

For this project, the relevant dependency manifests are:

frontend/package.json
frontend/package-lock.json
backend/pom.xml

Frontend Scan: npm audit

Use npm audit to inspect frontend npm dependencies for known vulnerabilities.

cd frontend
npm audit

To focus on high severity vulnerabilities and above:

cd frontend
npm audit --audit-level=high

npm audit reads package-lock.json, checks resolved dependency versions, and reports known npm advisories.

Use npm audit fix carefully. It may update dependency versions and should be reviewed as a dependency change. Do not apply automatic fixes blindly if the project is close to demo, release, or submission.

Backend Scan: OWASP Dependency-Check

Use OWASP Dependency-Check to inspect Maven dependencies for known CVEs.

cd backend
mvn org.owasp:dependency-check-maven:check

The first run can take longer because the tool downloads vulnerability data. Later runs are usually faster because the database is cached locally.

The generated report is usually written under the backend build output directory, such as:

backend/target/dependency-check-report.html

If the report path differs, check the Maven output for the exact location.

Why This Is Manual Instead Of CI

These tools are useful, but they can introduce CI noise:

  • vulnerability databases change over time;
  • a new advisory can make CI fail even when application code did not change;
  • some findings may be false positives or may not be exploitable in this application;
  • dependency fixes can require careful upgrade and regression testing.

For this project, the recommended workflow is:

Regular CI: tests, coverage, and build validation
Manual security scan: run before demo, release, or dependency updates

How To Interpret Results

When a scanner reports a vulnerability, review:

  • affected package or Maven artifact;
  • installed version;
  • fixed version, if available;
  • severity level;
  • whether the vulnerable code path is used by this project;
  • whether upgrading introduces breaking changes.

A good remediation flow is:

Scan dependencies
Review reported advisories
Upgrade only the affected dependency when possible
Run frontend/backend tests
Run coverage or build checks again
Document any accepted risk if a fix is not practical

Relationship To Existing Security Tests

Manual dependency scanning checks third-party package risk.

Existing backend security tests check application security behavior, including:

  • authentication requirements;
  • JWT token generation and validation;
  • invalid or missing token handling;
  • RBAC and role guard rules;
  • protected endpoint access.

Both are needed because they cover different risks:

Application security tests: validate our own auth and authorization logic
Dependency scanning: detect known vulnerabilities in third-party packages