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 caxa:

• Arbitrary code execution in caxa itself — A crafted project tree, environment variable, archive entry, or runtime parameter causes the TypeScript builder or Go runtime stub to execute attacker-controlled code outside the intended packaged application process.
• Unsafe extraction / path traversal — A packaged payload can write files outside the intended extraction directory, overwrite unrelated host files, or bypass extraction path checks.
• Portable runtime bundling bypasses — A packaged Node runtime or its supporting shared libraries are resolved from attacker-controlled locations instead of the intended bundled files.
• Command injection during build — User-controlled values escape the intended upx, go, or other subprocess command boundaries used by caxa.
• Supply-chain integrity issues — Compromise of published npm packages, release artifacts, GitHub Actions workflows, or the prebuilt Go stub binaries.
• Extraction cache isolation failures — A vulnerability that lets one packaged application incorrectly reuse or poison another application's extracted cache contents.
• Unexpected inclusion of sensitive files by default — A default packaging behavior that unintentionally includes secrets, credentials, or host-specific sensitive material from the input tree.
• Denial of service through malicious payload metadata — Crafted payloads, footers, or compression streams that cause unbounded memory, CPU, or disk consumption in caxa itself beyond expected packaging or extraction work.

The following are generally not considered security issues in caxa:

• Vulnerabilities in the packaged application — caxa packages existing Node.js applications. Bugs in the packaged app or its dependencies are the responsibility of that application's maintainers.
• Intentional visibility of packaged source code — caxa is a packaging tool, not a code-obfuscation or DRM product. Extracted application files being readable on disk is expected behavior.
• Third-party runtime vulnerabilities — Vulnerabilities in Node.js, UPX, Go, package managers, or operating system libraries should be reported to those upstream projects unless caxa introduces a distinct exploit path.
• Large application size or extraction time by itself — caxa intentionally packages application trees. General resource consumption from large inputs is expected unless it exposes a specific algorithmic complexity or bounds-check failure.
• Manual misconfiguration — Using --include-node or custom stubs in unsupported ways, or explicitly choosing insecure custom build inputs, is not by itself a caxa vulnerability.
• Automated scanner findings without impact — Reports consisting only of dependency CVEs or static scanner output without a demonstrated exploit path in caxa.

These require case-by-case evaluation:

• Default exclude behavior — Excluding too little can bloat binaries or leak metadata; excluding too much can break runtime behavior. Reports should show a concrete security or integrity impact, not just a packaging preference.
• Shared cache behavior — caxa intentionally reuses extraction caches for identical payloads. Reports must show cross-application interference or integrity compromise, not simply cache reuse.
• Portable Node library discovery — Reports involving unusual platform-specific dynamic library layouts are in scope if they show caxa loading attacker-controlled code or omitting required security boundaries.

caxa operates at the intersection of application packaging, archive creation, native bootstrap execution, and runtime extraction. Security responsibility is shared among caxa, its users, the packaged application, and upstream runtimes/tools.

caxa includes several security-relevant controls and defaults:

• Native Go bootstrap stub with footer and trailer validation
• Zip-slip protection during extraction
• Lock-based extraction to reduce cache corruption
• Portable Node bundling with explicit shared-library handling
• Content-addressed cache reuse for identical payloads
• Conservative default excludes for non-runtime node_modules content

For a deeper analysis of threats and controls, see docs/THREAT_MODEL.md.

Security fixes are applied to the latest major line and, when practical, to the immediately previous maintained release line.