By Michael Branson

Quick answer. As of September 2026, a secure-development requirement belongs in a custom application development contract only if it names a practice, an artifact that evidences the practice, and a person on your side who receives that artifact. Three published sources supply the practice vocabulary so a buyer does not have to invent it: NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, published February 2022, read September 2026, gives the practice groups a contract can reference; the OWASP Application Security Verification Standard gives verification requirements a contract can cite by numbered version and level; and CISA’s Secure by Demand guide names the artifacts a purchaser can require back from a supplier, including a software bill of materials and a published vulnerability disclosure policy. Six requirements carry that pattern into a development contract: name the practice framework and the level, a component inventory delivered at each release, a vulnerability disclosure and remediation path with clocks, evidence of security testing, a controlled build and release pipeline, and a right of independent verification. None of the six makes an application secure, compliant, or certified on its own; each names a practice, an artifact, and a recipient.

The security section of a draft statement of work for a custom application often reads as three sentences: the supplier will follow industry best practices. That clause cannot be breached, because nothing in it names a practice a court, an auditor, or your own security function can check, an artifact that proves the practice ran, or a person on your side who is supposed to receive that artifact. The VP of IT who signs the technical annex is the one who answers for the gap later, not the supplier who wrote the sentence. The sections below turn that clause into six requirements, quote each one from where it is published, and name the evidence to require back for each, as read in September 2026.

Why “industry best practices” is not a requirement

A requirement written as “industry best practices” fails the same test twice: it names no practice a reader can check against a published text, and it names no artifact a buyer can hold at the next audit. CISA’s own guidance to software purchasers states where a specification belongs: organizations can integrate product security considerations into the procurement lifecycle “during procurement, by integrating product security requirements into contract language, as appropriate” (CISA, Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem, page 1, August 2024, read September 2026, https://www.cisa.gov/resources-tools/resources/secure-demand-guide).

That guide is written for the purchaser of a finished software product. A custom application development engagement puts your organization in the analogous position: your development partner fills the role CISA calls the manufacturer, for the application it builds you rather than for a shelf product. Translating that guidance into a bespoke development contract, requirement by requirement, is what the rest of this page does. Whether a specific clause satisfies your obligations under any regulation is a determination for your contracting officer and counsel, not a question this page answers.

A different question, what already went wrong on a project that is already running rather than what to put in a contract before one starts, is covered on Software Development Challenges: 11 Common Problems and Solutions; this page does not repeat that catalogue.

Requirement 1: name the practice framework and the level

A contract clause that names no framework leaves “secure” undefined the day a dispute starts.

NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1, is described by NIST as “a core set of high-level secure software development practices that can be integrated into each SDLC implementation” (NIST SP 800-218, Abstract, February 2022, Final, read September 2026, https://csrc.nist.gov/pubs/sp/800/218/final). NIST’s own executive summary states that organizations should “express their secure software development requirements to third-party suppliers using SSDF conventions” (NIST SP 800-218, Executive Summary, page vi). Naming SSDF, and its version, in a contract gives both sides one published document to argue from instead of a phrase neither side can test.

The OWASP Application Security Verification Standard (ASVS), currently version 5.0.0 (published 2025-05-30, read September 2026 at https://owasp.org/ASVS/), is described by the project as providing “a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development.” A contract can reference ASVS by its numbered version and a stated verification level. A contract that instead references “the latest ASVS” points at a document that moves without notice: the same release record carries a rolling development tag ahead of the numbered release, so a numbered version is the only form a signed contract should cite.

Naming a framework and a version specifies what a practice is measured against; it does not by itself say whether the practice was followed on your application. That is a separate requirement, covered next.

Requirement 2: a component inventory delivered at each release

An application built from dozens of open-source and third-party components is only as trustworthy as the list of what is in it, and most contracts never ask for that list.

CISA’s Secure by Demand guide names the component inventory as both a supplier obligation and a purchaser-collected artifact. Under software supply chain security, it asks whether the manufacturer generates “a software bill of materials (SBOM) in a standard, machine-readable format” and makes it available to customers (page 3). Among the artifacts a purchaser can collect from a manufacturer, it lists “A Software Bill of Materials (SBOM) that lists third-party software components used by the product” (page 2) (CISA, Secure by Demand Guide, pages 2 to 3, August 2024, read September 2026).

Require the supplier to deliver a machine-readable inventory of every third-party component in the build, updated at each release, and name in the contract who at your organization receives it and what happens when a component in it is later found vulnerable, because an inventory nobody receives and nobody acts on is a deliverable rather than a control.

Requirement 3: a vulnerability disclosure and remediation path with clocks

A supplier that finds a vulnerability in your application and has nowhere written to report it decides on its own how fast you hear about it.

CISA’s guide asks purchasers to check “Whether the software manufacturer operates a vulnerability disclosure policy (which should be a public webpage)” (page 2) and, on the reporting side, “Has the software manufacturer published a vulnerability disclosure policy that authorizes testing by members of the public on products offered by the software manufacturer?” (page 3). On defects the manufacturer has not yet addressed as a class, it asks whether the manufacturer has “a roadmap showing how they plan to eliminate those classes of vulnerability” (page 2) (CISA, Secure by Demand Guide, pages 2 to 3).

Require the supplier to name, in the contract, the channel through which a vulnerability found in your application is reported to you, the severity scale it is rated against, and the remediation clock attached to each severity level. Your security function sets the scale and the clock; this page states only that the contract needs one, in writing, before the first defect is found rather than after. A published disclosure policy proves the supplier has a channel for the public; it does not by itself prove your application has a named channel, a scale, and a clock, which is why those three are written as your contract’s own terms rather than inferred from the supplier’s public policy.

Requirement 4: evidence of security testing, and what you actually receive

A supplier who says the application was tested has told you an opinion; a supplier who hands you a dated result against a numbered standard has told you a fact.

The OWASP ASVS gives a contract a way to state that fact rather than assume it: referencing a numbered ASVS version and level turns “the application was tested” into a testable claim, because the standard “provides a basis for testing web application technical security controls” against stated requirements. What the contract requires back is the result itself, dated and scoped to the release it covers, not a letter stating that testing occurred “according to industry standards.”

This requirement is placed on the development partner and is confirmed by the evidence in the register below; it is never something to take on faith because a supplier’s marketing page describes a commitment to security.

Requirement 5: a controlled build and release pipeline, and who can change it

A component inventory is only as trustworthy as the pipeline that assembled it, and a pipeline anyone can push changes to is not a controlled pipeline.

NIST’s SSDF groups its practices under four headings, and one states this requirement directly: “Protect the Software (PS): Organizations should protect all components of their software from tampering and unauthorized access” (NIST SP 800-218, Section 2, page 4, read September 2026).

Require the supplier to name, in the contract, who can change the build and release pipeline for your application, how that access is limited to people who need it, and how a change to the pipeline itself is logged. The contract does not need to name a specific tool; it needs to establish that the control exists and who signs off when it changes.

Requirement 6: a right of independent verification, and what triggers it

A requirement your own contract cannot check is a requirement in name only.

A contract that requires the five items above still needs a way to confirm they were met on the release you are accepting, and that confirmation carries more weight when it comes from outside the team that wrote the code. Require, in the contract, a right to commission independent validation and verification of the delivered application, including code review, at acceptance or at a stated trigger such as a major release or a finding under the vulnerability path above, and name who at your organization exercises that right. The methodology, deliverables, and governance of an engagement like this, and how to evaluate a partner for one, are covered on IV and V Best Practices for Regulated Enterprise Software Evaluation: Methodology, Deliverables, and Governance; the service itself is described on Independent Validation and Verification (IV&V) Services for Software Risk Control.

The evidence register: who receives what, and when

The six requirements above render as one register, so a contracting officer can check each line without re-reading the reasoning behind it.

Requirement What the contract says Evidence received Who receives it When
1. Framework and level Names NIST SP 800-218 and, where applicable, a numbered OWASP ASVS version and level The named document citation in the signed technical annex Contracting officer At contract signature
2. Component inventory Supplier delivers a machine-readable SBOM at each release The SBOM file, in the format the contract sets Records administrator or application owner At each release
3. Vulnerability disclosure and remediation Supplier names its report channel, severity scale, and remediation clock, and reports against them The written channel, scale, and clock in the annex; a report each time the clock is triggered Security function At signature, then at each reported vulnerability
4. Security testing evidence Supplier delivers a dated test result against the named ASVS level The test result, scoped to the release it covers Security function At each release or at acceptance
5. Build and release pipeline control Supplier names who can change the pipeline and how a change is logged The access list and the change log, on request Security function or its delegate At acceptance and on request
6. Independent verification right Buyer holds a right to commission IV&V at a stated trigger The IV&V findings report Contracting officer and security function At the stated trigger

Honest counter-case: the requirements not worth writing

A requirement whose evidence nobody on your side will read is a cost with no control behind it, not a safeguard.

Name a recipient for every requirement above before it goes into the contract, or drop the requirement: an evidence line with no reader is paperwork, not a control. An ASVS level set above what the application’s own data warrants prices out suppliers who would otherwise have served you well; set the level to the data the application holds, not to the highest number available. A small supplier may be able to meet the substance of a requirement, such as reviewing dependencies before adding them, without being able to produce the exact artifact format a larger supplier would hand over; a buyer who cannot tell a substantive gap from a format gap ends up selecting suppliers on paperwork rather than on practice. And if your organization is in financial services, the sector’s own regime, not this checklist, sets the specification first: the shortlist questions that follow from it are covered on How to Choose a Custom App Development Firm for Financial Services.

None of the six requirements above is a substitute for the determination your contracting officer and counsel make about what a specific agreement needs; this page states the shape of the requirement and the evidence behind it, not the clause language itself.

How i3solutions approaches it

This page sets out a framework for making this decision; it does not describe work i3solutions has delivered on this specific question. If your task is turning six requirements into contract language you can hand to counsel, the order matters more than the wording: name the practice, name the artifact, name the recipient, in that sequence, for each requirement before it goes into the annex.

This checklist sits under i3solutions’s Custom Application Development Services for Enterprise Performance, which describes i3solutions’s own custom application development work as end-to-end: consulting, development, testing, integration, implementation, and ongoing support. i3solutions has also published an engagement case study, named here as “Enhancing Quality With an IV&V Code Review,” describing an engagement in which i3solutions was engaged to perform an independent verification and validation (IV&V) code review of an application delivered by a separate development vendor, the kind of review a right of independent verification under Requirement 6 would call on.

If you want the six requirements above turned into contract language for your contracting officer and counsel to review, the conversation starts here.

Contact a senior architect

Key Takeaways

  • A secure-development requirement belongs in a contract only when it names a practice, an artifact, and a recipient on your side; “industry best practices” names none of the three.
  • Six requirements carry that pattern into a custom application development contract: the practice framework and level, a component inventory at each release, a vulnerability disclosure and remediation path with clocks, evidence of security testing, a controlled build and release pipeline, and a right of independent verification.
  • NIST SP 800-218 (SSDF Version 1.1) and the OWASP Application Security Verification Standard give the practice and verification vocabulary; a contract references ASVS by numbered version and level, never by “the latest.”
  • CISA’s Secure by Demand guide, written for purchasers of finished software products, is the source for the component-inventory, disclosure-policy, and remediation-roadmap artifacts translated into contract terms here.
  • None of the six requirements makes an application secure, compliant, or certified; each is a named practice with a named artifact and a named recipient, sized to what the application’s own data warrants.