State governments depend on software to deliver nearly every public service, from unemployment benefits and tax collection to licensing, public safety and healthcare. Yet most states, buy that software from vendors, systems integrators, and third-party development partners rather than building it themselves.
That arrangement has become so routine that many agencies treat it as a procurement exercise rather than a cybersecurity decision. The result is a critical blind spot hiding in countless state contracts: many never define what “secure software” means.
Instead, contracts often rely on vague language requiring vendors to follow “industry best practices” or provide software that meets general security standards. Those phrases are difficult to measure, verify, or enforce. If a contract does not define a specific security requirement, there is nothing the software can pass or fail before the state accepts delivery.
As a result, the first real security test frequently occurs after deployment, when a vulnerability is discovered through an audit, a third-party disclosure or a security incident. By then, taxpayers are often funding both the remediation and the disruption.
The answer is not more security language. It is measurable security language.
Midterm Elections Create a Rare Opportunity
Midterm election cycles often bring new governors, agency leadership, legislators, CIOs, and procurement officials. Multi-year agreements outlast headlines, and security teams are costly to change once signed.
For incoming CIOs and procurement leaders reviewing inherited contracts, one question matters most:
Does this contract define what secure software means?
If not, the state may be accepting significant software supply chain risk without realizing it.
You Can’t Test What You Don’t Define
Every technology contract should establish objective acceptance criteria for software security. Yet many contracts never specify what evidence must be provided, what testing must occur, or what level of risk is acceptable.
A traditional contract might require a vendor to “follow secure development practices.”
A stronger contract would require the vendor to:
- Perform specified application security testing before delivery.
- Remediate or formally document critical and high-risk vulnerabilities.
- Deliver a Software Bill of Materials (SBOM) for each release.
- Retest software after significant changes.
- Meet defined security requirements before final acceptance and payment.
General language creates obligations. Measurable language creates accountability.
Treat SBOMs as Deliverables, Not Checkboxes
Software bills of materials have become an important tool for understanding software supply chain risk. They show what components make up an application and speed response when new vulnerabilities emerge.
But requiring an SBOM alone is not enough.
Components are constantly added, updated, and replaced, so an SBOM generated at launch may no longer reflect the software running in production six months later.
States should therefore require SBOMs as ongoing contract deliverables tied to releases and defined milestones. They should specify when SBOMs must be delivered, how they will be maintained, and what level of detail they must contain.
Low-Code and No-Code Change the Equation
The rapid adoption of low-code and no-code platforms introduces another challenge.
These tools let agencies build and modify applications quickly, often with little involvement from traditional development teams, which means applications can change continuously after deployment. A security assessment conducted before launch may no longer reflect the application’s risk profile weeks later.
For that reason, contracts governing low-code and no-code applications should require ongoing testing rather than one-time validation.
Procurement Is a Security Function
Procurement is one of the most influential and overlooked actors in the software chain. Procurement officials determine what requirements ultimately become enforceable contract terms. Security teams can recommend controls, but procurement leaders decide whether suppliers must meet them.
The National Association of State Procurement Officials (NASPO) is particularly important because many states rely on cooperative purchasing vehicles rather than developing every contract from scratch. Strengthening the language in widely adopted frameworks improves security across many jurisdictions at once.
What State Leaders Should Do Next
State CIOs and procurement officers do not need new legislation to make progress. They can begin strengthening software supply chain security today by taking four practical actions:
- Replace generic security clauses with specific, measurable requirements.
- Require SBOMs as standard deliverables at defined milestones.
- Establish ongoing testing requirements for low-code and no-code applications.
- Tie software acceptance and payment directly to successful completion of agreed security requirements.
Most importantly, states should push these provisions into cooperative procurement vehicles, so the benefits extend beyond a single agency.
The most effective place to reduce risk may not be in the code itself. It may be in the contract that governs how that code is built, tested, and delivered.
If “secure” remains undefined, states are accepting risks they cannot measure. But when security requirements are explicit, testable and enforceable, governments gain something far more valuable than another promise from a vendor: a standard they can verify before software ever reaches a state network.
The author, John Savio, is Vice President of Public Sector at Black Duck.