H.9 Security
Security in a shared repository is a set of distinct trust decisions. Source read access, dependency permission, review approval, build execution, artifact promotion, and runtime authorization can involve the same person or path while still proving different things.
Draw The Trust Boundaries
H.9.1 Source Access defines who may read, clone, search, mirror, export, or contribute to each source domain, including history, indexes, backups, generated output, and review attachments. Confidentiality, regulation, or external collaboration can be a sound reason for a hard repository boundary.
H.9.2 Trust Boundaries then separates source hosts, review, CI, remote execution, caches, registries, deployment systems, and runtimes. Bazel visibility constrains dependency edges during analysis; it is not source confidentiality or runtime authorization. Every check, signature, and attestation should state the claim it does and does not prove.
Follow Authority From Input To Runtime
H.9.3 Credentials governs eligibility, approval, issuance, distribution, rotation, revocation, breakglass, and exceptions for distinct builder, cache, signer, publisher, and deployer identities. H.9.4 Supply Chain joins dependency integrity and provenance with vulnerabilities, license obligations, build authority, signing, SBOMs, registries, and promotion policy after H.5.6 Dependency Intake has established what may enter and who maintains it.
Use a threat-model trace: a third-party input is admitted with recorded source and digest; an eligible builder produces identified bytes; a separate signer attests the intended claim; an authorized promotion moves that artifact; the runtime accepts only the required identity. Compromise of one link must have a named response and invalidation scope.1
H.9.5 Security Audit records the security-sensitive events and tests whether their identities can actually be joined under declared access, retention, sampling, and completeness limits. Stored logs are not proof until an incident or artifact can be traced through them. Operational source-to-runtime diagnosis is owned separately by H.11.8 Delivery Traceability.
Name subjects, operations, resources, and proof at every trust boundary. Keep source access, graph policy, review, credentials, supply-chain claims, and audit joins separate enough that one control is never mistaken for another.
Footnotes
-
Building Secure and Reliable Systems — Ch. 14: Deploying Code — separated build, signing, promotion, and deployment authorities ↩
Sections in this chapter · 5
Define source confidentiality, access domains, external contribution, regulated data, and boundary-forcing constraints.
Separate source visibility, dependency policy, review authority, execution trust, artifact access, runtime authorization, and proof.
Govern credential eligibility, approval, issuance, distribution, rotation, revocation, breakglass, and exceptions by workload.
Continuously protect accepted dependency and artifact trust through provenance, integrity, signing, vulnerability, license, and compliance controls.
Define which security and compliance decisions must be provable, to whom, for how long, and within what completeness limits.
