With custom-developed software you can read, test and fix the code, but you own every flaw. With commercial off-the-shelf software (COTS) you usually cannot see the code, so you manage risk through vendor selection, contracts, configuration, isolation and monitoring. Both need an inventory, and both need a plan for when a flaw is announced.
What stays the same?
Both kinds of software run in your environment with your data. Both depend on third party components. Both get vulnerabilities, and attackers do not care who wrote the code.
NIST SP 800-161 Revision 1, on cybersecurity supply chain risk management, treats acquired and built software as part of one supply chain. Its message is to manage risk across the lifecycle, from selection through retirement.
How does risk differ for custom software?
You control the source. That gives you strengths and duties.
Strengths. You can apply secure development practices, run static analysis and tests, fix a flaw on your own schedule and know what ships. NIST's Secure Software Development Framework, SP 800-218, gives a checklist.
Duties. Nobody else is looking for your bugs. You own design review, dependency management, secret handling and the vulnerability process. Your open source dependencies are in your hands too, and a typical project has far more transitive packages than direct ones.
Typical failure. A team writes a clean application and never updates an old library. The code is yours, but the risk came in through the dependency tree.
How does risk differ for COTS?
You cannot patch it yourself, and you may not see inside.
Strengths. A vendor with a mature process may test more broadly than you could, and many customers find bugs faster.
Duties. Choose with evidence. Ask whether the vendor follows secure development practices, publishes advisories, supports a disclosure process and provides an SBOM. NIST's guidance on supply chain risk suggests building these expectations into contracts. Define patch timelines, notification of incidents and end-of-life terms.
Typical failure. A product reaches end of support but stays in production. Nobody is accountable, because nobody owns the decision to retire it.
What controls do you apply to COTS you cannot change?
- Harden the configuration and turn off unused features.
- Isolate it on the network and limit its outbound access.
- Give it the least privileged service account.
- Monitor logs for unusual behaviour.
- Keep a record of version, owner and support end date.
A constructed example
A company runs a commercial document management product and a custom portal built in-house. A critical advisory lands for a library used by both. For the portal, the team searches its SBOM, finds two services, updates the dependency and redeploys the same day. For the product, they have no control of the code. They check the vendor advisory, find that a patch is due in five days, and apply a temporary mitigation: block the vulnerable upload feature at the proxy and restrict access to the management interface. When the patch arrives they apply it in a test environment first.
Where does tooling help?
An inventory per build and SBOMs for custom software make questions quick to answer. For vendors, request SBOMs and keep them in the same place. Safeguard's SBOM and dependency scanning, reachability analysis and policy gates cover the custom side, while the COTS side depends on your contracts and configuration.
How to check or apply this
- List all software with owner, version and support end date, marking custom or commercial.
- For custom code, apply SSDF practices and scan dependencies on every change.
- For commercial products, add security terms to contracts and request an SBOM.
- Define patch and mitigation targets for both categories.
- Isolate and monitor products you cannot inspect.
- Review end-of-life dates each quarter and plan replacements.
Quick check
Is custom software more secure because I control it?
Not automatically. Control helps only if you apply secure development practices and keep dependencies current.
What can I do when a vendor is slow to patch?
Apply mitigations such as disabling the feature, isolating the system and restricting access, and press the vendor using your contract terms.
Sources
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices, NIST
- NIST SP 800-218, Secure Software Development Framework, NIST
- Securing the Software Supply Chain: Recommended Practices Guide for Customers, CISA
Last reviewed: 18 October 2026.
