NIST SP 800-53 SA-22: Unsupported System Components and End-of-Life Open Source

The short answer

NIST SP 800-53 Revision 5 control SA-22, Unsupported System Components, gives an organization two ways to comply. Either it replaces a component once support is no longer available from the developer, vendor or manufacturer, or it provides alternative sources of continued support, in-house, from external providers, or both. Running an end-of-life open source component is therefore not a failure of SA-22 on its own. Running one with no documented source of security fixes is.

The control's discussion says the external provider route works through contractual relationships, which "can include open-source software value-added vendors". This article is general information about the control text, not legal or audit advice.

The control text

SA-22 reads:

1. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
2. Provide the following options for alternative sources for continued support for unsupported components: [selection, one or more: in-house support; organization-defined support from external providers].

The organization fills in the selection, and if it chooses external providers it defines which support they give. In Revision 4 the alternative sources sat in a separate enhancement, SA-22(1). Revision 5 withdrew SA-22(1) and incorporated it into the base control, so part b is now part of SA-22 itself.

SA-22 appears in the low, moderate and high baselines of SP 800-53B. Federal systems assessed under FISMA and cloud services assessed under FedRAMP both draw their controls from SP 800-53, so this is the control an assessor reaches for when a scan or an inventory shows an end-of-life component.

What "support" means in the guidance

The discussion section defines support to include "software patches, firmware updates, replacement parts, and maintenance contracts". Its example of an unsupported component is one where vendors "no longer provide critical software patches or product updates". For open source, that is the date the project stops publishing security releases for a version line. A project's own announcement is usually the evidence assessors accept. Our end-of-life tracker records those dates for common runtimes and frameworks such as Spring Framework, Kafka, RabbitMQ and PostgreSQL.

The guidance also names exceptions to replacement: systems that provide critical mission or business capabilities where newer technologies are not available, and systems so isolated that installing replacement components is not an option. It suggests reducing the increased risk of unsupported components by "prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation". Isolation reduces risk, but it is not one of the two ways of meeting the control.

What an assessor examines

SP 800-53A lists the evidence for SA-22. The objects to examine are:

• the system and services acquisition policy
• procedures addressing the replacement or continued use of unsupported system components
• documented evidence of replacing unsupported system components
• documented approvals, including justification, for the continued use of unsupported system components
• the system security plan
• the supply chain risk management plan

Assessors also interview the people responsible for acquisition, information security, the development life cycle and component replacement, and test the processes and mechanisms for replacing unsupported components. In practice the question in the interview is simple: for each end-of-life component in the inventory, who supplies its security fixes now?

How SA-22 connects to SI-2, RA-5 and CM-8

SA-22 rarely surfaces on its own. CM-8 requires a system component inventory, and its discussion lists software version numbers among the information needed for accountability, which is how an end-of-life version gets noticed. RA-5 requires vulnerability scanning and remediation of legitimate vulnerabilities within organization-defined response times. SI-2 requires flaws to be identified, reported and corrected, and security-relevant updates to be installed within an organization-defined time period after release.

For an end-of-life component, SI-2 and RA-5 run into the same wall. When a new CVE is published against the version you run, there is no upstream update to install within your time period. That is why SA-22 asks where updates come from instead, and why a clean scan alone does not settle it. Per-CVE answers such as VEX statements help with RA-5 findings, but they do not show that a component is supported.

Evidence that closes SA-22 for an EOL open source component

Whichever route you choose, write it into the system security plan, and keep the SBOM accurate. A patched build should appear as its own component and version so scans and the SI-2 records agree.

Where OSSeva fits

OSSeva is an external provider of continued support in the sense SA-22 describes. OSSeva Patch ships drop-in builds with security fixes backported to community end-of-life open source runtimes, signed with GPG and attested with Sigstore Cosign, through your own repository manager. OSSeva Assure adds an architectural review and compliance documentation, with evidence matrices covering FedRAMP Moderate control families including SA and SI. The compliance library has the equivalent guides for SOC 2, PCI DSS and HIPAA.

Frequently asked questions

Does SA-22 prohibit end-of-life software?

No. It requires replacement or an alternative source of continued support. Documented in-house or external support satisfies part b.

What happened to SA-22(1)?

In Revision 5 the enhancement was withdrawn and incorporated into SA-22. The alternative support options are now part b of the base control.

Is network isolation enough to satisfy SA-22?

The guidance presents isolation as a way to mitigate the increased risk of unsupported components, and isolated systems as a possible exception to replacement. It is not listed as one of the control's two options, so expect the assessor to ask for an approval and justification as well.

Does a VEX statement satisfy SA-22?

No. VEX answers whether a product is affected by a specific vulnerability. SA-22 asks whether the component has a source of support at all.