Notifications
Clear all
Topic starter
21/08/2026 4:45 pm
TL;DR: Unused software components keep expanding cloud application attack surfaces, and Rapidsort argues that curated images, SBOM generation, and runtime profiling can reduce that risk while easing FedRAMP compliance. The deeper issue is not patching speed alone but whether teams can continuously prove what is actually running, what is exposed, and what can be removed.
NHIMG editorial — based on content published by Rapidsort: Optimize and Secure Your Cloud
By the numbers:
- 85% of enterprise software is open source, which increases the volume of components that must be validated and controlled.
- RapidFort says its approach can reduce the software attack surface by up to 90% without code changes.
- RapidFort says it can eliminate up to 99.9% of vulnerabilities within hours through component removal and hardening.
Questions worth separating out
Q: How should cloud teams reduce software attack surface without disrupting delivery?
A: Start by identifying which dependencies are actually used in production, then remove dormant packages and unnecessary libraries from base images.
Q: Why do unused software components create compliance risk?
A: Unused components create compliance risk because they widen the inventory that security teams must justify, scan, and remediate.
Q: How do you know if runtime evidence is better than static scanning alone?
A: Runtime evidence is better when it shows a smaller set of actually executed components than the build inventory suggests.
Practitioner guidance
- Standardise on runtime-verified SBOMs Use SBOMs to identify what ships, then use runtime profiling to confirm what actually executes in production.
- Create a dead-component removal workflow Build a recurring process to remove unused libraries, packages, and inherited dependencies before they accumulate across release cycles.
- Adopt hardened base images by default Replace ad hoc base images with curated, pre-hardened images for common runtimes so teams start from a smaller attack surface and fewer inherited vulnerabilities.
What's in the full report
Rapidsort's full whitepaper covers the operational detail this post intentionally leaves for the source:
- A breakdown of RapidFort Analyzer, Optimizer, Profiler, and CART across the software lifecycle
- The claimed workflow for generating SBOM and RBOM evidence for FedRAMP-aligned reporting
- The specifics of the near-zero CVE image catalog across Ubuntu, Debian, Red Hat, and Alpine
- The article's own discussion of how exploit-aware prioritisation is applied in practice
👉 Read Rapidsort's whitepaper on optimizing and securing your cloud →
Software attack surface reduction: what it means for cloud teams?
Explore further
21/08/2026 5:05 pm
Software attack surface debt is the right way to describe this problem: teams accumulate dormant packages, inherited libraries, and unused dependencies the same way identity programmes accumulate stale accounts and orphaned privileges. The issue is not simply vulnerability volume. It is the governance debt created when organisations cannot prove which components are truly in scope, which means compliance evidence becomes fragile and remediation becomes reactive.
A question worth separating out:
Q: Who should own software attack surface reduction in a FedRAMP programme?
A: Ownership should sit with both platform security and application teams, because the control spans image selection, build pipelines, and production runtime. Compliance teams need the evidence, but engineering teams must remove the components and keep the baseline stable across releases.
👉 Read our full editorial: Software attack surface reduction is becoming a compliance control
