Hopefully, heralding the start of what is a happier new year for everyone, today we are pleased to announce the availability of Anchore Enterprise 3.0. Over the past 18 months since our last major release, much has happened in the world of software security (and beyond!). From the software supply chain becoming a national security issue to the major developer platforms prioritizing DevSecOps in their roadmaps, the practice of hardening the entire software-delivery lifecycle is now front and center of all organizations.
We’ve taken a hard look at the fundamental challenges of taking a true “shift left” approach to cloud-native security. Finding vulnerabilities or flagging issues in software is not difficult. Every piece of software has something that could be of concern. The critical challenge is doing it to reduce developer friction by avoiding noise, providing relevant context, and clear remediation steps. Let’s drill into the major features of the 3.0 release, which help our customers achieve these goals. Check out our launch video:
Bringing the Kubernetes Context to Container Alerts
Anchore Enterprise has integrated with Kubernetes for a while, blocking images being deployed that fail to meet security standards. With 3.0, we’ve taken that a step further and now connect into the operational Kubernetes environment to catalog the running instances with our Kubernetes Inventory feature. We can flag any containers which have active vulnerabilities or are now failing policy or compliance checks that have run or are running Kubernetes. By marking the relevant image digest in your registry as being currently run in production and its being a security concern, developers can more easily prioritize their response to alerts.
A Distributed Model for CI/CD Scanning
Many security tools in the container space wait for an image to be published to a registry by the CI/CD system before scanning it, adding performance overhead and placing the burden of scanning on a central security platform. To distribute the processing effort and improve pipeline speed by reducing network traffic, we’ve completely refactored how we integrate with GitLab, GitHub, and other popular CI/CD tools. Our new Go-based Pipeline Scanner tool creates the Software Bill of Materials (SBOM) from the container image locally in the CI/CD platform itself and sends the results to the central Anchore system. Anchore then sends back the policy result to pass or fail the CI job. This new deployment model improves the operational cost of running the Anchore system while also simplifying the security scan’s operational overhead in the pipeline.
Helping Security Teams help Developers
You have security information from the pipeline scan and situational awareness from the Kubernetes inventory. What should a developer do next? Our Remediation Action Plans are a brand new addition to our user interface, allowing security teams to generate clear instructions for developers on how to resolve security alerts. Pre-populated suggestions created by Anchore Enterprise can be combined with contextual information and then sent out to popular messaging or ticketing systems. This powerful combination can help developers, who are probably not security experts, understand the options available to them, resolve issues faster, and allow additional research to be passed along by the security team.
Reducing False Positives
False positives are the bane of all security teams, wasting time and effort on wild goose chases. On the container input side, we added a “Hints'' capability in 2.4 which allowed developers to explicitly describe software content to help improve vulnerability matching and reduce false positives. In 3.0, we’ve added a new False Positive Management feature so security teams can modify artifact metadata after it has been extracted by Anchore’s system. This allows for gaps or inaccuracies in the data generated during a scan to be fixed thereby ensuring better fidelity with associated fields in the vulnerability database. This is particularly useful for particular language artifacts such as Java which either have inaccurate metadata or don’t have any data at all.
Finally, DevSecOps teams deal with false positives are often dealt with by allowlisting specific packages. This provides a quick and instant way to unblock a pipeline. However, allowlists tend to linger, making what is often intended to be a temporary reprieve to an image a permanent exception. This in itself can become a security concern as fixes are not followed up. With our new Allowlist Expiration feature, security teams can ensure that exceptions to deployments can be time-limited on a customizable value.
Looking Forward
Anchore Enterprise 3.0 is going to continue to receive regular updates throughout the year. We plan to continue adding more runtime features and deeper integrations with the CI/CD platforms while improving the fidelity of security information. As ever, we look forward to hearing from customers and do sign up for our upcoming Anchore 3.0 webinar entitled How to Secure Containers Across The SDLC.
