Thanks Jan for sharing this with us https://www.linkedin.com/pulse/z%25C3%25BCrich-devsecops-meetup-jan-jambor
The first part was a presentation including some demos helt by Ken. He has been working on automating certain aspects of his development process and shared some experiences and tools with us.
Detecting secrets in your code
Github recently started to scan repos for API keys and passwords and alerts the owners, some also have reported that AWS revokes API keys which are found in public repositories. Shhgit recently grabbed some attention as it collects information about publicly shared secrets.
Wouldn’t it be smart if a tool helps you to identify secrety in your commits before you send them off to github & co.? And thats what Ken has shown us in his first demo: Talisman. Installed as a pre-commit hook it checks for passwords and other secrets and aborts the commit when something is found.
There are also other tools like SonarQube avaiable for that tasks which also offer more features.
Where to store secrets
As we have been discussing secrets already, we discussed how to deal with them the right way. And here Ken has shown some vault solutions. HashiCorp Vault beeing one of the better known solutions, but also all of the big cloud providers offer their own solutions – like Azure Key Vault – which are also good. The point you have to concider is portability of your solution. So, no excuses anymore for hardcoded passwords, not even for testing. Don’t do that, it will come back on you quick and hard.
Package managers and dependencies
The short version of this part of the demo is: all package managers are fundamentally broken. Not only do we have a ton of dependencies for simple “hello world” apps, there are unknown potentially insecure packages which are not well updated. One example of SQL injections is shown on the picture below (source: https://snyk.io/blog).
The big SaaS source code repository solutions like github have introduce security checks for package managers and dependencies of your app. But also, on prem solutions can be enhanced with appropriate checks in the build pipeline.
Dynamic analysis scanning
We also quickly discussed the OWASP top 10 which is suprisingly (or not suprisingly?) not changing that much over decades. There are many tools out there, commercial and open source to help you with dynamic analysis. OWASP itself has a huge list of tools on their website.
Infrastructure as code
Infrastructure as code is also a huge topic. Most of the time it heavily relies on components and images pulled from public resources. Just like packages mangers mentioned above we have unknown and potentially insecure sources of these components. Here static analyzers like Clair for Docker images come into play and help identify potential problems.
Update: I just found vulnerablecontainers.org, a huge collection of public available containers images (e.g. docker hub) with scan results, this should be pretty alarming if you are using these images out of the box in production.
Now we have seen many different tools and sources of “noise” in a security officers’ day to day business. What we need is a way of keeping track of the important things, basically a “nagios” for DevSecOPS is required. Ken has shown us archery sec which just does that. It helps you collect all the information from the different sources and identify the really important points in all that noise.
The second part of the meetup was presented by Adrian Kosmaczewski, responsible for Developer Relations at VSHN who introduced us to the very cool upcoming project SYN which should help to cover the 5 big points of DevSecOPS: GitOPS, maintenance, logging, trusted sources and Policy management.
Some huge pluses in my eyes are:
First: everything will be open source, not only the code but also the whole discussion about the specs and most important the organization which makes a big difference. Just putting a project on github is in my eyes not even close to the complete job. Try to make one of the Apache projects like Superset work in a PoC in less than one day and you’ll see what I’m talking about.
Second: Adrian described it as “low hanging” fruits when he said, that project SYN will integrate with the big 3 cloud providers (AKS, EKS and GKE) and also existing clusters. That’s a huge plus in my eyes. I have been looking in similar solutions like nginx’s new controller v3.0 which only supports complete new created clusters on bare metal or VMs which is a huge problem from my point of view. So, if project SYN is delivering nearly what has been promised here: huge!
Third: VSHN eats their own dogfood! And they have by far the most experience when it comes to cloud native infrastructure, Kubernetes and Open Shift. So, what we will see here is, what powers VSHN every day. And this cannot be bad.
Some sneak peeks Adrian has shown to us:
A huge point is the close cooperation with crossplane. This rather new solution helps to manage cloud-native apps and VSHN making use of it and contributing to it in return is a huge plus for both. Some more tools which are used are listed below (not a full list).
The second Zürich DevSecOps Meetup was big success in my eyes. I’m really looking forward to the next meetup.
In the meantime, I’m going to the Hands-on docker image security best practices workshop which is on March 9th 2020 (as far as I know fully booked but if you are interested sign up for the waiting list). And of course I’m in for the DevOPS Day Zurich in September 2020.