If you sell software to a federal agency, you have probably lived this already. You spend weeks pulling together an attestation form. Then a memo comes out, the form becomes optional, and nobody tells you what replaces it. You ask your contracting officer. They are not sure either. You ask another agency you work with, and they have a different answer.
Part of that is how the rules get enforced. Secureframe’s 2026 State of Federal Cybersecurity Report surveyed more than 850 defense contractors, subcontractors, assessors, and federal suppliers. Half of them said assessors interpret the same requirement differently. Another 44% said they struggle to predict what evidence an assessor will ask for. When the people checking the work cannot agree on what the work is, the vendor in the middle gets a different answer every time.
That is the normal state of federal software security right now. The rules are moving. But the moving parts are not as random as they look. Once you understand what each framework is for, a lot of the confusion around federal government compliance drops away.
What Federal Software-Security Compliance Means
Federal software-security compliance is the set of duties a vendor owes when its software or cloud service touches a federal agency. Those duties are not one certificate. They change depending on four things.
- What kind of software you make.
- What system it supports.
- What the agency decides it needs.
- What your contract says.
That last one catches people off guard. Two companies can sell similar products to two different agencies and face very different asks. One agency wants a software bill of materials. Another wants a secure development attestation. A third wants penetration test reports. A fourth wants all three.
It also depends on what you are selling. Commercial software is treated differently from custom-built software. A cloud service is treated differently from an on-premises tool. Software that supports a federal information system carries heavier expectations than software that never touches federal data.
There is no single federal compliance stamp that covers everything.
Key Federal Compliance Frameworks
The government does not have one software security law. It has several frameworks, each doing a different job. The table below gives the basics.
| Framework or requirement | What it covers | Who it mainly affects |
| FISMA and NIST Risk Management Framework (RMF) | Federal information-security risk management and system authorization | Federal agencies and organizations operating federal information systems |
| NIST SP 800-53 | Security and privacy controls for information systems | Federal agencies and system owners, including contractors where applicable |
| NIST SP 800-218 (SSDF) | Recommended secure software-development practices | Software producers and organizations applying secure development practices |
| EO 14028 and OMB software-security policy | Federal software supply-chain security policy and its development | Federal agencies and software suppliers within applicable requirements |
| OMB Memorandum M-26-05 | Risk-based software and hardware assurance policies, agency risk assessments, and inventories | Federal agencies and suppliers subject to the resulting agency policies and contract terms |
| FedRAMP | Standardised assessment and certification of cloud services within the programme’s scope | Cloud service providers pursuing FedRAMP certification and the federal agencies using those services |
None of these apply to every vendor in the same way. Several of them overlap, which is actually helpful. A control you build for one framework often counts toward another.
Note: The right-hand column shows who usually feels each framework first. It is not a list of everyone who must comply. Your contract and your agency’s policy decide that.
FISMA and the NIST Risk Management Framework
FISMA is the law that makes federal agencies responsible for protecting their information and systems. The NIST Risk Management Framework is how agencies carry that out. It moves them through six core steps. Categorize the system. Select controls. Implement them. Assess them. Authorize the system. Monitor it.
If you are a contractor, FISMA matters when you run a system for an agency or when your product supports one. When a contractor operates a federal information system, or provides a system that falls within an agency’s authorisation process, the agency must assess the applicable security controls before authorising the system to operate. The authorisation to operate (ATO) applies to the system, not automatically to every individual software product. Your software may need to provide security evidence that supports the agency’s assessment and authorisation decision.
NIST SP 800-53 Security Controls
NIST SP 800-53 is the control catalog. It lists the security and privacy controls agencies use to protect federal systems. Access control. Audit logging. Configuration management. Incident response. Supply chain risk management. It is all in there.
You do not need to memorize the catalog. You do need to know which controls apply to your product and how you can show they are working. That is where many vendors get stuck. They can describe their security well in a sales call. They cannot produce evidence when an assessor asks.
NIST SP 800-218 Secure Software Development Framework
The SSDF is the one most software producers should read first. It groups secure development into four practice areas. Prepare the organization. Protect the software. Produce well-secured software. Respond to vulnerabilities.
NIST writes it for software producers and for the agencies that buy software, which is why the same document shows up in vendor conversations and procurement reviews.
The framework stays out of the way. It does not tell you which tool to buy. It tells you what good development looks like. Secure build environments. Multi-factor authentication for developers. Trusted source code supply chains. Vulnerability scanning. A process for handling reported vulnerabilities.
NIST is updating it as well. It published an initial public draft of SSDF version 1.2 in December 2025. The draft proposes changes to the existing framework, including practices related to continuous improvement and reliable software updates. It is a proposed revision, not a new mandatory requirement for every software producer. The core point stays the same. Secure development is not a project you finish. It is a habit you keep.
Federal Software Assurance After OMB M-26-05
This is the change that has caused the most confusion this year.
On January 23, 2026, OMB issued Memorandum M-26-05. It rescinded M-22-18 and M-23-16, the two memos that had required agencies to collect a standard secure software development attestation from software producers.
OMB was direct about why. The earlier approach, in its own words, imposed “unproven and burdensome software accounting processes that prioritized compliance over genuine security investments.” It also pulled agencies away from building assurance requirements around their own threats.
So what replaced it? Not a free pass. M-26-05 moves federal software and hardware assurance toward risk assessments that each agency runs on its own. Every agency now has to build its own assurance policy based on its mission and its risk tolerance. Agencies also still have to keep complete inventories of the software and hardware they use.
The table below shows what changed in plain terms.
| Before M-26-05 (M-22-18 and M-23-16) | After M-26-05 |
| One standard attestation form, collected by agencies | Attestation form is optional; agencies decide whether to use it |
| A single federal process for software assurance | Each agency builds its own risk-based assurance policy |
| Government-wide attestation mandate; SBOM available at agency discretion | Attestation optional; SBOM still available at agency discretion through contracts |
| Vendors tracked one federal requirement | Vendors track what each agency they work with asks for |
| Agencies kept software inventories | Agencies still keep complete software and hardware inventories |
Two practical points matter for vendors.
- The CISA attestation form did not go away. It is now optional. Agencies can still use it, and some will.
- Agencies can still require an SBOM through contracts when they decide it fits.
Agencies can still include SBOM requirements in contracts. Under M-26-05, they may require software producers to provide a current SBOM upon request. For cloud platforms, the memo says the contract should specify that the SBOM covers the runtime production environment. Whether a particular vendor must provide one depends on the applicable contract terms.
One thing that gets missed is that the shift puts more monitoring work on vendors, not less. Under the old memos, one standard federal form covered you across agencies. Under the new approach, you have to keep track of what each agency you work with decides to ask for. The government-wide attestation approach under those two memos has ended. Agency-specific assurance policies and contract requirements now play a larger role.
That is not all bad. It gives vendors room to have a real conversation about risk instead of filling out the same form every year. But you cannot assume last year’s compliance package still works.
FedRAMP for Cloud Services
If you provide a cloud service that stores, processes, or maintains federal information, FedRAMP is probably in your future. It is the government’s standard way of assessing cloud security, and it builds on FISMA.
FedRAMP changed in 2026. It officially launched the Consolidated Rules for 2026 on June 24, 2026, with optional early adoption beginning July 4, 2026. The word “Authorization” is now “Certification.” The old Low, Moderate, and High impact levels are replaced by Certification Classes A through D. The classes reflect different levels of assurance and assessment expectations, but they do not map one-to-one to the former impact levels. Agencies still categorise their own systems by potential impact, and FedRAMP’s classes help them judge the assurance evidence available for a cloud service.
The vulnerability rules changed too. Instead of ranking findings by scanner severity alone, providers will have to consider how exploitable a finding is, whether it is reachable from the internet, and what impact it could have on an agency. Those rules take effect on December 7, 2026, for services getting or keeping certification. The clock is running.
There is a short grace period. FedRAMP provides a grace period through March 7, 2027, during which providers may maintain certification under a corrective action plan that includes notice to agencies. Treat December 7 as the compliance date. March 7 marks the end of the specified grace period, not the date to aim for. (FedRAMP Notice NTC-0014, June 2026).
Cloud providers should read this as a warning. FedRAMP certification is not a finish line. It comes with continuous monitoring duties, and the way findings get prioritized is about to change.
Who Must Meet Federal Software-Security Requirements
Federal agencies, software producers, government contractors, and cloud service providers all have duties under federal software-security rules. The duties are not the same.
- Federal agencies are responsible for their own systems and for how they use third-party software.
- Software producers may need to supply attestations, SBOMs, or secure development evidence, depending on the contract.
- Government contractors may face requirements passed down from the agency, including flow-down clauses to subcontractors.
- Cloud service providers may need FedRAMP certification before an agency can use the service at all.
What ties them together is that duties follow the contract, the agency’s policy, and the system involved. There is no universal answer to “am I covered?” Federal government compliance depends on what you sell, who you sell it to, and what it does.
Key Secure Software Development Requirements
Frameworks do not secure anything on their own. The real work happens in engineering. These six practices come up again and again across federal requirements, and they make a real difference.
- Secure design and threat modelling. Before anyone writes code, ask what can go wrong. Threat modelling finds design problems early, when they are cheap to fix.
- Secure coding and source-code review. Many vulnerabilities are avoidable. Coding standards, peer review, and static analysis catch obvious mistakes before they reach production.
- Dependency management and Software Bills of Materials (SBOMs). Most modern software is other people’s code. You need to know what is inside your product and which parts have known vulnerabilities. An SBOM is the inventory that makes that possible.
Security Practices for SBOM Compliance
CISA’s 2026 minimum-elements guidance adds requirements for component hashes, licence information, the SBOM tool name, and the context in which the SBOM was generated. It also emphasises machine-readable, structured SBOM data. These are baseline expectations for usable SBOMs, not a standalone legal mandate. The generation-context field matters because it tells a reader whether the SBOM came from a build, a release, or somewhere else in the pipeline.
1. Development environment and CI/CD pipeline security.
Attackers go after the build process because compromising the pipeline lets them compromise everything that comes out of it. Secure build environments, multi-factor authentication, and provenance records are not nice-to-haves anymore.
2. Vulnerability scanning and penetration testing.
Scanners find known issues. Penetration testing finds what scanners miss. Logic flaws, access control mistakes, and chains of small weaknesses that only show up when a person actually tries to break in.
4. Vulnerability remediation, disclosure, and ongoing monitoring.
Finding a vulnerability is half the job. You need a process to fix it, a way for researchers to report issues, and monitoring that catches new risks as they appear.
The gap between producing SBOMs and actually using them shows why the practice matters more than the paperwork. Cloudsmith’s 2026 Artifact Management Report found that 75% of teams generate SBOMs, but only 25% have built automation around consuming them. And ENISA’s 2026 SBOM adoption survey found that 62% of respondents rated achieving a high degree of SBOM completeness as quite difficult or extremely difficult. In other words, most teams can produce the document. Fewer can trust it or act on it quickly. That is the part assessors and agency reviewers tend to ask about.
The same pattern shows up across the other practices. Teams can usually point to a scanning tool or a review process. What they struggle to show is that the process ran consistently, that findings were fixed, and that there is a record someone else can check.
Specific requirements depend on the framework, agency policy, and contract. But every framework comes back to these six things.
Federal Software-Security Compliance Checklist
A federal compliance checklist is not a 200-page plan. It is a sequence that keeps you honest about what you have actually done, in the order an assessor will ask about it.
- Identify applicable federal policies, frameworks, and contractual obligations. Read the contract. Read the agency’s policy. Work out what actually governs your product.
- Map requirements to security controls. Turn the legal language into controls your team can own.
- Document secure development practices. Write down how you design, build, test, and release software. Then keep the artifacts that show those steps actually happened, because an assessor will ask for the record, not the policy.
- Assess application, API, infrastructure, and dependency security. Look at the whole surface, not just the code your team wrote.
- Track vulnerabilities and remediation. A finding without a fix date is just a note. Assign it, track it, close it.
- Maintain required assessment reports, attestations, and audit evidence. Evidence is what compliance runs on. Keep it current.
- Review security risks and controls regularly. Agency requirements change. Threats change. Your review should keep up.
How Qualysec Supports Software-Security Compliance
Qualysec helps software vendors show that their security controls actually work through web, API, mobile, and cloud penetration testing, secure SDLC and DevSecOps assessments, and retesting after fixes.
No penetration test makes you federally compliant. Compliance is a legal and contractual status. What a security assessment does is test the controls you are claiming against something real.
Qualysec is listed in the CREST marketplace for penetration testing. CREST’s accreditation process assesses providers against defined standards for technical competence and service delivery. The firm’s work covers:
- Web, API, mobile, and cloud penetration testing, including manual testing that goes beyond what automated scanners catch.
- Secure SDLC and DevSecOps assessments, reviewing how security is built into design, development, and release.
- Vulnerability validation and remediation guidance, so findings come with a clear path to a fix rather than a raw scanner output.
- Retesting and security assessment reports, with evidence-backed documentation you can hand to an auditor or an agency reviewer.
That matters for federal work because agencies and assessors want evidence, not assurances. A penetration test report does not replace an attestation or an SBOM. But it gives you something real to point to when an agency asks whether your software has been tested, whether the findings were real, and whether they were closed.
The firms that handle federal compliance well are not the ones with the thickest paperwork. They are the ones that can show a working security program underneath it. Qualysec helps close the distance between what you claim and what you can prove.
Conclusion
Federal software security in 2026 is less about one form and more about a habit. The rules moved this year, but the direction is the same: show the work, not just the paperwork. OMB M-26-05 pushed agencies toward risk-based, agency-specific decisions. FedRAMP is tightening how vulnerabilities are prioritized. CISA has updated its minimum-elements guidance for SBOMs, adding data fields and a stronger emphasis on machine-readable, structured SBOM data. NIST is updating the SSDF so that secure development is treated as a continuous practice.
Vendors who wait for a single federal answer will keep getting stuck, because that answer does not exist anymore. Vendors who build secure development into how they work, keep evidence ready, and treat federal government compliance as something that follows good security instead of replacing it will do fine.
Secureframe’s report found that half of respondents said assessors interpret the same requirement differently, and 44% struggle to predict what evidence an assessor will ask for. Those findings help explain why vendors need clear records of their security controls and the evidence to support them. A program built only to pass a review will pass the review and miss the thing the review was meant to catch.
If you are not sure where your software stands, start with an honest technical assessment. You cannot fix what you have not measured, and you cannot prove what you have not tested.
If you want to know where your software stands, Qualysec offers a free consultation to scope a technical assessment. You can reach the team at sales@qualysec.com or schedule a call through the contact page. No pitch, just a conversation about what an assessor will ask for and what you can show today.
FAQs
1. What does federal software-security compliance actually require?
It depends on your contract and the agency. There is no single certificate. Duties vary by software type, the system it supports, agency policy, and contract terms. SBOMs, attestations, and penetration test evidence may all be requested.
2. Do I need FedRAMP if I sell software to the federal government?
Only if your cloud service falls within FedRAMP’s scope. That generally means it creates, collects, processes, stores, or maintains federal information on behalf of an agency. On-premise software and defense contractors themselves do not need FedRAMP certification.
Not every cloud use is in scope. FedRAMP excludes certain services, including search engines and some commercially available information services that do not collect federal information on the agency’s behalf. Defense contractors handling covered defense information must ensure their cloud service meets FedRAMP Moderate-equivalent security requirements under DFARS 252.204-7012. This is not the same as FedRAMP certification. The agency determines whether its intended cloud use falls within FedRAMP’s scope.
3. Does OMB M-26-05 mean SBOMs are no longer required?
No. M-26-05 rescinded the government-wide secure software development attestation policy and made the CISA attestation form optional for agencies to use. But agencies can still require SBOMs through contracts, including a current SBOM upon request. Whether you must provide one depends on the applicable contract and agency requirements.
4. Is being compliant the same as being secure?
No. Compliance is a legal and contractual status. A security assessment shows whether your controls actually work. A program built only to pass a review can pass the review and still miss the real risk the review was meant to catch.
