Vulnerability management

Last updated: 2026-04-11 • ← 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

• 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 are 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

A Software Bill of Materials (SBOM) is generated for the Backbuild platform on every push to main by the backbuild-security-scan.yml CI workflow. The SBOM is produced in CycloneDX 1.5 JSON format and enumerates direct and transitive dependencies along with their versions and licenses.

• 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.

Until the first publication run completes, the file at /security/sbom/latest.json contains an explicit "x-placeholder": true flag so that automated compliance scanners do not mistake the seed file for a real zero-component SBOM. The API origin redirects /v1/security/sbom.json to the trust-site copy in production.

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 targeted for 2026. See penetration testing for details.