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 publishes 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 by the backbuild-security-scan.yml CI workflow and committed back to the trust site so the published URL always reflects the latest codebase.

• Latest SBOM: /security/sbom/latest.json — updated automatically on every merge to main.
• Dated snapshots: immutable copies are committed alongside latest.json as /security/sbom/sbom-YYYY-MM-DD.json and retained indefinitely as audit evidence for SOC 2 Type II and ISO 27001:2022.
• 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.
• Signed SBOMs and historical releases: available on request to security@backbuild.ai under NDA.

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 Cloudflare Workers runtime is patched by Cloudflare 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 Cloudflare 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.