Anchore has made its open source Grype vulnerability scanner tool for containers generally available for DevOps teams that are running the latest version of the GitLab continuous integration/continuous delivery (CI/CD) platform.
Anchore Grype leverages Syft libraries that employ deep inspection algorithms to create an accurate software bill of materials (SBOM) for an application and then runs a scan to identify vulnerabilities.
Zach Hill, director of engineering for Anchore, says that data is then surfaced within a GitLab workflow to advance adoption of DevSecOps best practices.
Applying those best practices to container applications, however, often proves challenging given the ephemeral nature of containers that are often ripped and replaced. Developers are being required to continuously scan for vulnerabilities that might be lurking in the software components encapsulated in containers both before and after deployment in a production environment.
Many developers are counting on the fact that the vulnerabilities will only be exposed for a short period of time, since containers are replaced frequently. However, cybercriminals only need a few seconds to land malware that they can activate later. It’s also worth noting that, as more stateful applications are built using containers, the amount of time a container might be running is starting to get longer.
Most of the security incidents that involve containers have typically involved some form of cryptojacking. Generally considered a nuisance crime, it allows cybercriminals to siphon compute resources from victims to mine cryptocurrencies. The prevalence of cryptojacking activity shows that container platforms can be compromised. As more digital business transformation initiatives are launched based on containerized applications built using microservices, the odds that container environments will be targeted by cybercriminals starts to exponentially increase.
In the wake of some recent high-profile breaches of software supply chains, many of those containerized environments are already coming under increased scrutiny. While most organizations would prefer to see DevOps teams deploy more secure applications in the first place, it takes time to reengineer software development processes. Developers also need to be trained to not only recognize vulnerabilities but also remediate them. As a result, many cybersecurity teams have been given new mandates to make sure the existing software supply chain is as secure as possible until DevOps teams attain higher levels of security expertise and maturity.
Of course, the faster security tools are added to DevOps workflows, the sooner that goal can be accomplished. The challenge is making sure the tools added to those workflows are based on command line interfaces (CLIs) and application programming interfaces (APIs) that DevOps teams will actually use. Too often, DevOps teams are presented with security tools based on graphical user interfaces (GUIs) that are preferred by cybersecurity professionals with limited programming skills.
At this juncture, it’s only a matter of time before applications become more secure. Processes will evolve as the DevOps culture continues to evolve. The hurdles that need to be overcome at this point are more cultural than technical. Unfortunately, changing the culture of any organization requires time that, as software supply chains are attacked more frequently, many organizations simply lack.