GitHub has been a key vendor in making the developer experience friction-free and many of the features they announced this week at their GitHub Universe conference continue to set the standard.
What was notable at the event this week was that security has now been added to the fiction-free mantra and, for anyone who has worked in the security industry, this is not a combination of words you typically hear. Indeed security is mostly seen as being a friction-adder par excellence, so it was really encouraging to see security as the core theme of the day 2 keynote, along with multiple product announcements and talks. Ensuring that security can be added to container workflows with as little overhead as possible is at the core of Anchore’s mission and a key driver of general DevSecOps practices. The fact that GitHub, as the largest hoster of open source content in the world, is getting behind this is great for everyone in the community.
As we announced two days ago, we spent a number of weeks collaborating with GitHub to produce our Anchore Container Scan action. As Zach Hill, Chief Architect at Anchore, and Steve Winton, Senior Partner Engineer at GitHub, demonstrated at one of the breakouts, starting with as little as 4 lines of YAML, you can add Anchore to a CI/CD workflow to generate a full scan of a container and use the output to pass or fail a build. It is hard to conceive of a simpler way to add security to the software development workflow. No manual crafting of Jenkins build jobs, no post-hoc scanning of a content registry – just a simple event-driven model that takes a few minutes to run.
The ability to piece multiple actions together is the most interesting part of the GitHub Action story. The obvious workflow for developers to instrument is to build a container with their code, scan it using to Anchore, push it to the Github Packages registry and then deploy it with one of the AWS, Azure or Google cloud actions. But linking this to other security capabilities in GitHub is where it gets interesting. You could programmatically: create GitHub issues with information about security issues found and how to resolve them for developers to act on; create security notifications (or even a CVE) for users to see about your product; or, push all the resulting data from your scans to a database for security researchers to mine.
We do seem to be at a moment in the industry where the scale of the problem is clear, the urgency to fix is now felt more broadly within organizations, and, finally, the tools and processes to start fixing it are becoming credible. By removing the friction, GitHub and others are hopefully reducing the cost of improving security while making the benefit ever more clear.
As we continue to develop the Anchore Container Scan action, we’re keen to hear your ideas about how we can improve it to support these types of workflows. So please provide feedback in the repo or drop us an email.