Vulnerability management

Last updated: 2026-04-14 • ← Security program

Backbuild runs a continuous vulnerability management program covering application dependencies, platform runtimes, and third-party components. The goal is to detect vulnerabilities quickly, prioritize them by severity, and remediate them within documented service level targets.

Dependency scanning

Automated dependency scanning runs in CI via the backbuild-security-scan.yml GitHub Actions workflow. The following controls are active:

• Pull request gate: every pull request is scanned for known-vulnerable dependencies before merge. A scan failure blocks merge until the finding is addressed or an accepted risk is documented.
• Tools: scans run in GitHub Actions using pnpm audit and osv-scanner against the current lockfile.
• Continuous scanning: in addition to per-PR scans, the main branch is scanned on a scheduled basis to catch vulnerabilities disclosed after a pull request was merged.
• Transitive dependencies: scans cover the full dependency tree, not only direct dependencies.

Software Bill of Materials

Backbuild maintains a machine-readable Software Bill of Materials (SBOM) in CycloneDX 1.5 JSON format, enumerating direct and transitive dependencies along with their versions and licenses. The SBOM is regenerated on every push to main so it always reflects the latest codebase.

• Availability: the SBOM is provided to customers and prospective customers on request, under a mutual non-disclosure agreement. It is not published publicly, so that a detailed dependency and version inventory is not made available to potential attackers. Request it from security@backbuild.ai.
• Format: CycloneDX 1.5 JSON. Compatible with Dependency-Track, OWASP Dependency-Check, Vanta, Drata, and any tooling that consumes the CycloneDX 1.5 JSON schema.
• Audit evidence: dated, immutable snapshots are retained as audit evidence for SOC 2 Type II and ISO 27001:2022, and are available under NDA alongside signed SBOMs and historical releases.

Severity classification and SLAs

Findings are triaged and assigned a severity based on exploitability, exposure, and blast radius. The following response SLAs apply from the point at which a finding is confirmed:

Severity	Remediation target
Critical	24 hours
High	7 days
Medium	30 days
Low	90 days

When a vulnerability cannot be remediated within its SLA, a documented exception is recorded with a justification, compensating controls, and a revised target date. Exceptions are reviewed on a recurring basis.

Patch management

• Platform runtime: the serverless edge compute runtime is patched by the platform provider on its own schedule, which Backbuild monitors as part of vendor management.
• Application dependencies: tracked and updated on at least a monthly cadence, and more frequently when a critical or high severity advisory is published.
• Operating systems and managed services: patching of underlying cloud infrastructure is inherited from the edge platform and the managed database provider. Patching cadence is reviewed as part of the sub-processor due diligence program.
• Emergency patches: a documented emergency change process allows for out-of-band remediation when a critical vulnerability requires it.

Third-party assessments

• Quarterly vulnerability assessment: a recurring third-party vulnerability assessment is planned as part of the compliance roadmap.
• Annual penetration test: an annual engagement with an independent security firm is in planning, with the first formal engagement scheduled for Q3 2026. See penetration testing for details.