A prospective government customer asks your team to attest that your software is developed in a secure environment and that you maintain provenance data for the source code you ship. Your pipeline builds on shared runners, release tags are pushed by whoever is on duty, and nothing is attested today. Walk me through how you would answer them.

What the interviewer is testing

Whether you can convert a procurement requirement into an engineering plan, and whether you know the difference between a document that describes a control and a control. The trap is treating this as paperwork, because the signature on the form is a representation by an officer of the company.

The clarifying questions that change the answer

• Which instrument? A producer self-attestation is a signed representation; a third-party assessment is an audit. The engineering work is similar and the evidence burden is not.
• Which boundary? The shipped artifacts, or every third-party component inside them. Flow-down to dependencies is where these commitments get expensive.
• What counts as evidence? An SBOM, machine-verifiable provenance, a policy document, or a demonstration.
• How long must the evidence live? A release supported for 3 years needs its provenance for 3 years.

A strong answer's arc

Start with the mechanism of the ask. Executive Order 14028 produced NIST's Secure Software Development Framework (SP 800-218); OMB memorandum M-22-18 (September 2022) requires agencies to obtain a self-attestation from the producer that it follows that framework, and CISA publishes a common self-attestation form covering secure build environments, a trusted source-code supply chain, provenance data maintained for the source, and automated vulnerability checking. The form is signed by a company officer, so inaccurate answers are a legal exposure, not a failed audit finding.

Then the technical gap list, cheapest first:

1. Release only from the hosted builder. No developer-machine releases, which is provable because the artifact's provenance names the builder.
2. Move tagging and publishing to the pipeline identity, which makes "whoever is on duty" irrelevant and removes a human from the trust path.
3. Generate provenance per artifact and retain it for the support window, with the verification material published.
4. Produce a dependency inventory per artifact, so the vulnerability question has a denominator.

Use a level ladder to make the conversation finite: SLSA Build L1 is provenance that exists and may be unsigned, L2 is a hosted platform that generates and signs it, L3 is a hardened platform where a build cannot forge its own provenance. Most teams reach L2 in roughly 2 to 6 weeks on a hosted builder with keyless signing; L3 is a platform project measured in quarters. Tell the customer which gaps are policy and which are platform, with dates.

Then say what it costs. Items 1 and 2 remove a convenience: nobody releases from a laptop again, including at 02:00 during an incident, so break-glass has to be designed rather than improvised. The decision rule worth stating out loud: attest only to properties a pipeline enforces, and close the rest with dates, unless the customer will accept prose — and prose is what later becomes the finding.

Common weak answers

• "We will write the policy document." The form asks what you do. Describing a control you do not operate is the single worst outcome available here.
• "We already sign our images." A signature binds a publisher to bytes. Provenance binds bytes to inputs. The question is about the environment and the source, which a signature does not address.
• "We have SOC 2." Different scope, different evidence. It helps the conversation and does not answer the ask.
• "We will add an SBOM." An inventory without provenance cannot answer whether the artifact was built from the reviewed source, which is the claim being made.

What a strong answer adds

Name what you will not attest to, and when that changes. Say how third-party components are handled, since they will never attest: pinned digests, verified builds for the few that matter, an upgrade commitment for the rest. And put one negative test in the pipeline — an artifact built outside the hosted builder must fail the deployment gate — because that test, not the form, is what makes the attestation true next quarter.