The OWASP cdxgen team and community take security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.

To report a security issue, email security@cyclonedx.org and include the word "SECURITY" in the subject line.

The OWASP cdxgen team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.

Report security bugs in third-party modules to the person or team maintaining the module.

We use the following target response and resolution times for reported security issues. These SLAs are best-effort commitments, not contractual guarantees.

After remediation is available, we will publish a GitHub Security Advisory (GHSA) with CVE assignment where appropriate.

The following are considered genuine security issues in cdxgen:

• Remote code execution (RCE) — An attacker-controlled input (manifest, lockfile, environment variable, server request) leads to arbitrary code execution within cdxgen itself.
• Command injection — Unsanitized input reaches safeSpawnSync or any child-process API in a way that escapes the intended command boundary.
• Path traversal in server mode — A request to the cdxgen HTTP server (--server) allows reading or writing files outside the configured CDXGEN_SERVER_ALLOWED_PATHS.
• Bypass of secure mode controls — A technique that circumvents protections enforced when CDXGEN_SECURE_MODE=true or the Node.js --permission model is active (e.g., host allowlist bypass, HTTPS enforcement bypass, command allowlist bypass).
• Supply-chain integrity — Compromise of the npm package, container images, GitHub Actions workflows, or release provenance attestation.
• Credential or secret leakage — cdxgen unintentionally writes secrets, tokens, or credentials to SBOM output, logs, or error messages during normal (non-debug) operation.
• Server-side request forgery (SSRF) — The cdxgen server or cdxgenAgent HTTP client can be tricked into making requests to unintended internal hosts when allowlists are configured.
• Git clone exploits — A crafted Git URL provided to the server bypasses validateAndRejectGitSource to execute code, use dangerous protocols (ext::, fd::), or access disallowed hosts.

The following are generally not considered security issues in cdxgen:

• Vulnerabilities in scanned projects — cdxgen intentionally parses untrusted manifests and lockfiles. Malicious content in those files that causes the scanned project's own build tools (npm, Maven, pip, etc.) to execute code is expected behavior of those build tools, not a cdxgen vulnerability. cdxgen's secure mode mitigates this by restricting package installations.
• Vulnerabilities in upstream build tools — Bugs in npm, Maven, Gradle, pip, Go, Cargo, or other package managers invoked by cdxgen are the responsibility of those projects. Report them to the respective maintainers.
• Dependency vulnerabilities with no demonstrated impact — A CVE in a transitive dependency of cdxgen that is not reachable or exploitable in cdxgen's usage context is not a cdxgen vulnerability. We still appreciate reports and will evaluate reachability.
• Debug-mode information disclosure — When CDXGEN_DEBUG_MODE, CDXGEN_TRACE_MODE, or CDXGEN_THINK_MODE is explicitly enabled, verbose output is expected and may include file paths, environment details, or command arguments. This is by design for diagnostic use.
• Denial of service via large inputs — cdxgen processes arbitrarily large projects. While we enforce buffer limits and timeouts, processing a very large monorepo may consume significant resources. This is expected behavior. Specific algorithmic complexity attacks (e.g., ReDoS) are in scope when triggered by untrusted project, registry, network, or server-client input.
• ReDoS from trusted pattern arguments — ReDoS or excessive CPU use that requires an operator to intentionally supply pathological glob/regex values through trusted CLI options or environment variables (for example, --exclude, --include-regex, --exclude-regex, ASTGEN_IGNORE_FILE_PATTERN, or Atom ignore env vars) is not considered a cdxgen security vulnerability. Wrappers or server deployments that expose these options to untrusted users should validate or constrain them at their own boundary.
• Self-hosted infrastructure access — Reports about the configuration of our CI/CD runners, GitHub Actions, or container registries that require pre-existing privileged access to those systems.
• Findings from automated scanners without proof of impact — Reports that consist solely of automated scanner output (e.g., "Snyk found CVE-XXXX in dependency Y") without a demonstrated exploit path in cdxgen.
• Social engineering or phishing — Attacks that require tricking a cdxgen maintainer into running malicious commands.
• HBOM collection gaps caused by host setup — Missing native utilities, lack of passwordless sudo, or host policies that block optional HBOM enrichments are operational setup issues rather than security vulnerabilities in cdxgen. Use hbom diagnostics to identify these cases.

These require case-by-case evaluation:

• Environment variable poisoning — cdxgen reads many environment variables. The auditEnvironment function detects dangerous patterns in NODE_OPTIONS, JVM arguments, and other variables. Novel bypass techniques for auditEnvironment are in scope. However, an attacker who can set arbitrary environment variables in the cdxgen process typically already has code execution.
• Unicode / encoding attacks — cdxgen validates against dangerous Unicode in paths and hostnames via hasDangerousUnicode. Novel bypass techniques are in scope.
• Container escape — Issues that allow escaping the cdxgen container are in scope if the escape vector is specific to cdxgen's container configuration. Generic container runtime vulnerabilities should be reported to the runtime vendor.

cdxgen operates at the intersection of source code analysis, build tool invocation, and SBOM generation. Security responsibility is shared among cdxgen, its users, upstream build tools, and the broader ecosystem.

cdxgen includes several built-in security features. See the following documentation for details:

• Permissions Model — Node.js --permission integration and CDXGEN_SECURE_MODE
• Allowed Hosts and Commands — Per-language allowlist reference
• Environment Variables — All CDXGEN_* environment variables including security-related ones
• HBOM Guide — Host inventory options, diagnostics, and least-privilege collection guidance
• Threat Model — Detailed threat model for cdxgen components

Security fixes are applied to the last two releases and cover the last two CycloneDX specification versions. Users are encouraged to stay on the latest version.