Companies that use Elastic Container Registry (ECR) tend to start out using AWS Inspector for its SOC 2 vulnerability reporting, but many end up replacing it because of the lack of context regarding your applications and developer workflow. That lack of context adds noise, double-counting of issues, frustration, and overhead to your security program.
EdgeBit has helped customers through this journey and this post maps out the steps along the way for your first app to hundreds of services.
Lacking application context
AWS Inspector introduces noise into your backlog of security issues because it lacks context about where your apps are deployed. Many container images stored in your ECR are no longer actively deployed, and some may have never been deployed. For a SaaS service, vulnerabilities within these inactive container images are not relevant.
EdgeBit tracks containerized workloads running in ECS (Fargate & regular) clusters, EKS & other Kuberentes distros, and EC2 machines, and continually matches them with an inventory of the vulnerable packages and libraries contained within.
The outcome is simple but incredible for your team: EdgeBit has a rolling knowledge of the set of vulnerabilities that matter for each of your apps. New issues are easily spotted and when vulnerable versions are no longer running, the issue is marked as resolved.
For a high profile CVE, EdgeBit makes it easy to observe which teams have rolled out fixes and which ones haven’t. Remember, you’re not done until a fix is both merged and deployed. EdgeBit closes out issues as soon as they are deployed, not when the registry’s garbage collection happens to run.
Lacking developer workflow context
Another short-coming of AWS Inspector is its inability to prevent problematic code from being merged. It’s ten times easier to prevent a vulnerability from being introduced into your application than it is to manage it once it’s already been deployed to production.
The developers on your team can identify and fix problems on their own, which leaves them less frustrated. Plus, the AppSec team never needs to be involved nor do they need to manage the tracking of SLA commitments.
Inside a Pull Request, EdgeBit identifies differences in package versions between the committed changes and the target branch. New issues are flagged and in normal situations the GitHub check is green and the developer’s workflow remains the same, but EdgeBit is there protecting them behind the scenes.
Lacking tuning and configuration
Your teams may use really slim base images, internal base images, or several “thicker” base image distros, plus all of their app code. The ability to tune and configure how the scanner detects OS packages and ecosystem specific packages is key to preventing annoying false positives.
A concrete example of this is a Dockerfile or package.json present inside the test cases of a package used in your container. These aren’t part of your application or threat surface and any parsing of these for vulnerabilities results in noise, but many scanners find them anyway.
EdgeBit’s use of Software Bills of Material (SBOMs) as the inventory mechanism (learn more) gives each customer the choice of tools and configuration to obtain the most accurate representation of their app. Our team has lots of suggestions for how to be successful with all of your apps.
Gain fully automated project management for your vulnerabilities
EdgeBit’s automatic remediation, powered by workload tracking, removes all of the manual project management by developers and engineering managers. Never ask if a fix was deployed or if an SLA was met…it’s all tracked for you and syncs to all of your tools.
What is nirvana? It looks like this:
- Jira issue is created and tagged with a due date for every new security issue
- Tasks are pulled into sprints with little fuss
- Fixes are merged and traced by their commit digest
- Jira issue is automatically closed once no vulnerable workloads are observed
- Remediation SLA calculated automatically and synced to your SOC 2 compliance tool
What’s definitely not nirvana?
- Double and triple-counted vulnerabilities
- Noise related to container images that will never be deployed
- Noise related to container images that are no longer running
Reach out to one of our engineers to hear how we’ve replaced AWS Inspector and the roadmap to get here. It’s a short journey and provides a meaningful quality of life change for your engineers.
