Under the federal secure-development attestation regime, who attests for a subcontractor's component in a prime's deliverable?

## The rule first The federal secure-development attestation is made by **the producer of the software the agency acquires**. If a prime integrator delivers a system to an agency, the prime attests — for the whole thing. A subcontracted component sits inside that scope exactly like an imported open-source library does. The subcontractor does not attest to the agency; it usually has no privity with the agency at all. That single fact answers the question, but it is not what the interviewer is looking for. What they want to know is whether you understand the difference between transferring risk and reducing it. ## Flow-down is contract, not control The standard response to being on the hook for someone else's build is a flow-down clause: the prime's contract with the sub requires the sub to make the same commitments, provide the same artifacts, and indemnify the prime if it lied. That is worth doing. It is also, on its own, almost worthless as security. - The prime's officer signature is still the one made to the government. A sub's promise to the prime does not move that. - The sub's assurance covers the sub's pipeline, which the prime has never seen and will never see. - Recovery from a sub after the fact is money, and the failure being reduced here is not a money failure — it is a tampered artifact running inside a government system. - The sub has its own subs. Flow-down clauses stack indefinitely and nobody verifies the far end. This is the attacker position that makes the question worth asking. A compromised or coerced supplier one link out is inside your deliverable but outside your visibility, and the compromise reaches the agency wearing your name. ## What the prime can actually verify A senior answer pivots from collecting assurances to verifying artifacts. Concretely, what a prime should require of a subcontracted component: **Provenance.** A signed statement, produced by the sub's build system rather than by a person, binding the delivered artifact's digest to the source revision it was built from and the builder that produced it. This is verifiable evidence about origin, and it is checkable by machine at the moment you ingest the component. **An SBOM for the component.** Not because the SBOM proves anything about integrity — it does not — but because your own bill of materials for the delivered product is incomplete without it, and "we don't know what is inside the module our sub gave us" is not an answer you want to give an agency after a widely exploited library is disclosed. **Digest-pinned handoff.** The component enters your build by immutable content identifier, not by a tag or a branch the sub can move after you approved it. Otherwise what you verified and what you shipped are different things. **A disclosure channel with a clock.** A named contact and a contractual obligation to notify you within a defined window when a vulnerability affects the delivered component, because your obligation to the agency does not pause while your sub decides whether to tell you. **Verification you actually perform.** All of the above is theatre unless the prime's pipeline checks it on receipt — signature valid, digest matches, provenance names the expected source repository and builder — and fails the build when it does not. Requiring artifacts you never check is the most common version of this failure. ## The judgment layer Two tensions are worth naming out loud. First, **leverage is uneven.** A small subcontractor may be unable to produce build provenance at all, and a prime that demands it as an absolute may simply lose that supplier. The workable posture is graded: require the strongest evidence from the components with the largest blast radius, accept weaker evidence plus compensating checks — your own rebuild, your own scan, tighter runtime confinement — for the rest, and put a date on closing the gap. Second, **you can sometimes remove the trust relationship instead of assuring it.** If the sub delivers source and the prime builds it, the prime's own pipeline becomes the attested build and the sub's pipeline stops being in the trust path at all. That is not always possible commercially, but it is the answer that actually shrinks the problem rather than documenting it, and interviewers notice when a candidate reaches for it. ## What to say in the room Open with the rule — the seller attests for the whole delivered product, subcontracted parts included. Say plainly that flow-down transfers risk without reducing it. Then list what is verifiable rather than assertable: provenance bound to the artifact, an SBOM to complete your own, digest-pinned intake, a disclosure clock, and a pipeline gate that enforces all of it. Finish with the graded posture, because a blanket demand you cannot enforce across every supplier is the same failure in a different costume.