What does US Executive Order 14028 require from a company selling software to a federal agency?
answer
- It binds buyers, not builders
- Reaches vendors through the contract
- An assertion about practice, not product
- Attestation baseline, SBOM on request
basics
~20 sEO 14028 binds federal agencies, not vendors directly. It reaches sellers as a procurement condition: an agency may buy software only from a producer who attests to following NIST secure-development practices, and the agency may also require an SBOM.
solid answer
~50 sExecutive Order 14028 is an instruction to the executive branch, so it never regulates a vendor directly — it reaches you through what agencies are told to put in their contracts. Its software supply-chain section directed NIST to publish secure software development guidance and NTIA to publish minimum SBOM elements, and directed that federal purchases be conditioned on the producer's conformance with that guidance. In practice, implementing OMB memoranda require an agency to obtain a self-attestation from the software producer, on a common CISA form, that the product was developed following NIST's secure-development practices; the agency may additionally require artifacts, an SBOM among them. It is an assertion about how you build, not a certification that the software is free of vulnerabilities and not a government audit. The particular forms, memoranda and deadlines have been revised more than once, so learn the mechanism rather than the calendar.
go deeper
Recall the one-line shape: an order to federal agencies that becomes a condition in contracts, requiring the software producer to attest to secure-development practices, with an SBOM as something the agency can also demand.
Be ready to trace the chain — order to agencies, NIST guidance and SBOM minimum elements, OMB memoranda, a common attestation form — and to say precisely what the attestation asserts and what it does not.
Show the operational consequence: for each practice asserted, some team owns evidence, and gaps become documented plans rather than quiet omissions. Expect to be asked how you would produce that evidence on demand.
Own the framing that a procurement condition buys a document, not an outcome, and decide how much internal program you fund against it — the same evidence serves commercial customers copying the clause, so build it once.
## What EO 14028 actually is Executive Order 14028, *Improving the Nation's Cybersecurity*, was signed in May 2021. An executive order is an instruction from the President to the executive branch: it binds federal agencies and the people who run them. It does not, and structurally cannot, regulate a private software company the way a statute or a regulation does. The reason every software vendor ended up talking about it anyway is simple — the United States federal government is an enormous buyer, and the order told agencies to change *what they are allowed to buy and on what terms*. That is the whole transmission mechanism, and candidates who miss it give a confidently wrong answer about "the law that makes you produce SBOMs". ## The supply-chain section The order's software supply-chain section did three things that matter to a seller. First, it told NIST to publish guidance on secure software development practices. That guidance is what the later attestation points at — a set of practices for how software is built, reviewed, protected and released, not a list of controls in the shipped product. Second, it told NTIA to publish the *minimum elements* an SBOM must contain, so that "provide an SBOM" would have an agreed floor rather than meaning whatever a supplier felt like sending. (What those elements are is a separate subject; here the point is only that the order created the requirement to have them defined.) The order also framed SBOM delivery as providing it to the purchaser directly **or** publishing it, which is why "do we have to send one with every release?" has a contractual answer rather than a universal one. Third, it directed that federal purchases be conditioned on producers meeting that secure-development guidance, and told agencies to apply the requirements first to software the government designated as critical, rather than to every utility at once. ## How it reaches you: the attestation The order set direction; OMB memoranda turned it into agency behaviour. Agencies must obtain, from the producer of software they use, a **self-attestation** that the software was developed in line with the NIST secure-development practices. CISA published a common form so that a producer is not answering forty differently-worded questionnaires from forty agencies. Where an agency prefers, an assessment performed by an accredited third-party assessor can stand in place of the producer's own self-attestation. Three properties of that attestation are what interviewers actually probe: - **It is about practice, not product.** You are asserting how the software was built. You are not certifying that it has no vulnerabilities, and a CVE published next week does not falsify your attestation. - **It is not an audit.** Nobody from the government inspected your pipeline. It is your assertion, made to the government, with the consequences that attach to assertions made to the government. - **It covers the product you sell, whole.** Third-party libraries and open-source components you incorporate are inside the thing you attest for. What sits outside is software an agency develops itself, and freely available open source the agency obtains directly rather than through you. ## What it is not It is not a certification you can display. It is not a licence to sell. It is not a security standard in the sense of a control catalogue you can be assessed against pass/fail. And it does not, by itself, oblige you to hand an SBOM to anyone — SBOM delivery is an artifact an acquiring agency may require, and the terms live in the contract you signed, not in the order. ## The spillover The most practical consequence for engineers who will never touch a federal contract is that the federal wording became the nearest available template for everyone else. Once a mandate produced concrete contract language — attest to secure development, provide a bill of materials per release — state agencies, regulated industries and large private buyers began copying that language into ordinary commercial deals, sometimes verbatim, including scoping phrases written for federal procurement that make little sense elsewhere. If a commercial customer hands you a clause that reads like the federal one, read what was actually copied; do not assume the federal scope, thresholds or exclusions came along with it. ## What a vendor does about it The engineering work behind the attestation is evidence: for each practice you are asserting, someone inside the company must be able to show what makes the claim true, and there must be a defined internal path by which that evidence reaches whoever signs. If you cannot honestly assert a practice yet, that is documented as a gap with a plan rather than papered over — an agency may accept a documented plan, but it will not accept a claim that turns out to be false. Finally: the named memoranda, the form revision and the deadlines in this area have all changed more than once since 2021, and will change again. Answer with the mechanism — agency obligation becomes contract condition becomes producer attestation, with SBOM as a requestable artifact — and flag that the specific instrument of the day is something you would confirm before signing anything.
- Does the attestation cover the open-source components inside your product?Yes. The producer attests for the product it sells, including third-party and open-source code it incorporates — you cannot carve out "that part isn't ours". What sits outside is software the agency develops itself and freely available open source the agency obtains directly rather than through you. That inclusion is exactly why producers end up pushing secure-development expectations down onto their own suppliers.
- Is an SBOM automatically delivered with every attestation?No. The attestation is the baseline artifact; an SBOM is one of the artifacts an acquiring agency may additionally require, and the order also contemplated a producer publishing one rather than mailing it to each purchaser. Treat "we attest" and "we ship an SBOM per release" as two separate obligations that a given contract may impose together, separately, or not at all.
- Why do commercial customers who are not federal agencies now ask for the same thing?Because the federal clause became the nearest available template. Once a mandate produced concrete wording, private buyers, state bodies and regulated industries copied it into their own contracts — often verbatim, including scoping language written for federal procurement. Answering one well starts with reading what was actually copied rather than assuming it carries the federal scope and exclusions with it.
It works like a landlord's rule that every contractor on site must sign that they follow a safety method. The rule is imposed on the landlord's staff; contractors feel it only because nobody may hire them without the signature.
saying these in an interview costs you the question
- Calls EO 14028 a law regulating all software vendors
- Says it certifies the software is free of vulnerabilities
- Assumes an SBOM ships automatically with every attestation
- Confuses attesting to practices with passing a government audit
- Thinks open-source components are outside what you attest for