SA-20, Customized Development of Critical Components, says to reimplement or custom develop a list of critical system components that the organization names. The list is organization defined, so the control is empty until you decide what belongs on it.
800-53 binds US federal systems, and others through contract. For a small or mid size company it is a reference, and a rare one. Most teams will use it as a prompt to ask which component they would never run if they had a choice.
What it means in practice
The guidance explains the trigger. Some components likely cannot be trusted because of specific threats and vulnerabilities, and no viable control reduces the risk enough. Rebuilding or custom developing such a component can meet higher assurance needs by changing hardware, software or firmware so that standard attacks are less likely to work.
The guidance also admits the usual reality. Sometimes no alternative source exists and the organization chooses not to rebuild. In that case it can add controls: enhanced auditing, restrictions on source code and system utility access, and protection from deletion of system and application files.
For a software company, think of a parser that has produced repeated memory safety bugs, an abandoned library at the center of your product, or a cryptographic routine you were never meant to maintain. SA-20 is the decision record for those.
Evidence to collect
- The named list of critical components, with the reason each is on it.
- The decision for each: rebuild, replace, or keep with extra controls.
- For rebuilt components, design notes, test results and review records.
- For components you keep, evidence of the extra controls such as audit logs and access restrictions.
Common gaps
An empty list. Teams often have no component they consider critical because nobody has asked.
A list with no decision. Naming a component and then doing nothing is not a plan.
Rebuilding without testing. A custom component is only more trustworthy if you test it harder than the one it replaced.
How to implement it
- Start from your dependency and component inventory.
- Rank by impact and by known weakness, using vulnerability history and maintenance status.
- For the top few, choose rebuild, replace or contain, and write the reason.
- If you contain, add the controls from the guidance and show they work.
- Revisit the list when a component loses support or a serious flaw appears.
What an auditor may ask
- Which components did you judge critical, and why those?
- What did you decide for each, and when?
- For any you kept as is, which extra controls apply and how do you know they work?
An honest short list with decisions beats an empty one.
Quick check
What if you cannot rebuild a critical component?
The guidance suggests extra controls: enhanced auditing, restrictions on source code and utility access, and protection from deletion of files.
