CVE Lite CLI

The project utilizes granular GitHub Actions permissions, explicitly defining contents: read at the job level to adhere to the principle of least privilege.

Workflow dispatch triggers and manual inputs are subject to strict validation logic within the CI/CD configuration to prevent injection or misuse.

[version_unique]

The project maintains a formal policy of utilizing GitHub Secrets for encrypted storage, with zero hard-coded credentials allowed in the source or history.

Met. Release tarballs are signed via GitHub Artifact Attestations using Sigstore's ephemeral OIDC-issued keys, generated per build — no long-lived private signing key exists on either GitHub or the npm registry, satisfying the requirement that the private key not live on the distribution site. Verified end-to-end against v1.12.1 using gh attestation verify cve-lite-cli-1.12.1.tgz --repo OWASP/cve-lite-cli. Verification process documented at https://github.com/OWASP/cve-lite-cli#security-and-verification. [signed_releases]

Met. Release tarballs are signed via GitHub Artifact Attestations using Sigstore's ephemeral OIDC-issued keys, generated per build — no long-lived private signing key exists on either GitHub or the npm registry, satisfying the requirement that the private key not live on the distribution site. Verified end-to-end against v1.12.1 using gh attestation verify cve-lite-cli-1.12.1.tgz --repo OWASP/cve-lite-cli. Verification process documented at https://github.com/OWASP/cve-lite-cli#security-and-verification. [signed_releases]

The project’s SUPPORT.md defines the lifecycle for major releases, confirming that security updates are prioritized for the current stable version.

Justification: Documentation explicitly states that support for a version terminates upon the release of a subsequent major version that supersedes its architecture.

Justification: Escalated permissions (e.g., maintainer status) require a formal review by the Project Lead to establish identity and technical trust before approval.

Every release of the CLI is accompanied by an auto-generated SBOM (using GitHub's dependency graph or npm inventory) to ensure supply chain transparency.

Every release of the CLI is accompanied by an auto-generated SBOM (using GitHub's dependency graph or npm inventory) to ensure supply chain transparency.

Yes, the software uses Jest to run unit tests. There are currently 178 unit tests and 15 suites. All tests are passing [test]

I have established a formal policy that requires automated tests for all major new functionality added to the CVE Lite CLI. This mandate is documented in our project's contribution guidelines, where I specify that no pull request for new features will be merged unless accompanied by corresponding test suites. By enforcing this through my automated CI/CD pipeline, I ensure that our scanning engine maintains its high branch coverage and long-term technical integrity.

URL: https://github.com/OWASP/cve-lite-cli/blob/main/CONTRIBUTING.md#testing-policy [test_policy_mandated]

Branch protection rules require at least one manual approval from a maintainer other than the author before any Pull Request can be merged.

Met. Assurance case published at https://owasp.org/cve-lite-cli/docs/security-assurance-case covering all four required elements: threat model (five threat-actor classes with reachable surfaces), trust boundaries (data-flow diagram and per-boundary trust treatment table), secure design principles applied (Saltzer and Schroeder mapped to concrete project behavior), and common implementation weaknesses countered (full OWASP Top 10 (2021) mapping). The page is reachable from the README "Security and verification" section and from the project's security policy at SECURITY.md. [assurance_case]

Justification: The project publishes VEX-aligned assessments to clarify when standard CVEs are non-exploitable due to the CLI’s specific architectural design.

The scanner uses itself to scan for CVEs [dependency_monitoring]

The scanner uses itself to scan for CVEs [dependency_monitoring]

The scanner uses itself to scan for CVEs [dependency_monitoring]

I take confirmed vulnerabilities very seriously. Any medium or higher severity exploitable issues discovered by my static analysis tools-such as ESLint or GitHub CodeQL- are prioritized for immediate remediation. I have a strict policy that no major production release, including the recent v1.10.0 milestone, is published until all such confirmed vulnerabilities are resolved.

My commitment to a "timely" fix typically means addressing these issues within the same development cycle they are identified. By integrating these checks directly into my automated CI/CD pipeline, I ensure that security remains a gatekeeper for the project's integrity. This proactive approach ensures that the global developer community using the CVE Lite CLI can trust the tool's own supply chain and technical foundation. [static_analysis_fixed]

To fulfill the static code analysis requirement for the OSSF Best Practices Badge, I apply multiple FLOSS tools to every production release of the CVE Lite CLI, ensuring the codebase is scrutinized for security vulnerabilities and architectural flaws before it is made public. My foundational static analysis workflow utilizes ESLint, which I have configured to perform deep analysis of the source code. This process goes significantly beyond standard compiler warnings by identifying patterns that could lead to logic errors or maintainability issues. By making these checks a mandatory part of my local development and pre-release routine, I ensure that every contribution meets a high standard of technical health.

In addition to this linting layer, I have integrated GitHub CodeQL into the project's automated CI/CD pipeline. CodeQL performs sophisticated semantic analysis and data-flow tracking, effectively treating the code as a database to identify complex security issues that traditional tools cannot detect. By running these scans on every pull request and major release-including the recent v1.10.0 milestone - I ensure that the "Secure by Design" philosophy I advocate for the industry is strictly applied to the tool’s own development. This process acts as a mandatory quality gate that must be passed before any code is merged into the main branch or released to the community. [static_analysis]