I’m interested in understanding the challenges faced organisation in shifting security left during the DevOps cycle. What are the best frameworks and tools out there when it comes to DevSecOps and achieving maturity in this space?
There are so many challenges. Here are some big ones:
Cultural Shift: Shifting security left requires a cultural shift within the organization. Traditional silos between development, operations, and security teams need to be broken down, and a collaborative mindset must be fostered to ensure security is everyone’s responsibility. That sounds like something you read off the back of a marketing flyer doesn’t it!?! Well, it’s what everyone talks about because it’s super critical. There isn’t an answer for the best approach on this i.e. if you fit appsec eng into scrum teams or whatever model you adopt because it’s impossible to prescribe something that works well in one organisation because it may not in another. The key to success here is top down and bottom up transformation. Create policies, frameworks that define “what good looks like”, develop the best practices and guidance, and empower your teams to cross skill and collaborate.
Lack of Awareness and Training: Developers may lack the necessary knowledge and skills in security practices. Providing adequate training and awareness programs is essential to bridge this knowledge gap and empower developers to write secure code. Things like the CSSLP are a good starting point. In most organisations, Dev teams significantly outnumber Sec teams so rather than be disadvantaged by this, spin it around - identify those developers whom fit the mould of a security champion and empower them to drive that from within their team, and to help other teams. Develop a security champion program. IMO, starting here rather than diving straight into something like Secure Code Warrior is a better option. SCW is a great platform but I’ve seen too many times where it gets trialed and then not used, because the culture or basic training isnt there to adopt it properly.
Continuous Monitoring: Ensuring continuous monitoring throughout the software development lifecycle is critical to success - and I don’t mean monitoring of vulnerabilities, I mean monitoring the processes and tooling you have in place. Continuously evaluate it, so that it can be improved upon and grow as teams grow.
To achieve maturity in the DevSecOps space, organizations can leverage several frameworks, methodologies, and tools. Some of the popular frameworks and tools in the DevSecOps domain include:
OWASP DevSecOps Maturity Model: It provides a framework to assess an organization’s maturity in integrating security into DevOps practices. It offers guidance on progressing through different levels of maturity and identifying areas for improvement. This is a fantastic starting point.
CIS Benchmarks: The Center for Internet Security (CIS) provides comprehensive security benchmarks for various platforms and technologies. These benchmarks offer best practices and configuration guidelines to strengthen security in the DevOps environment.
NIST are another mention. And recently, CISA released some guidance but I feel it was quite limited: https://www.cisa.gov/securebydesign
What I have found works quite well is deriving a bespoke framework and drawing from these resouces - an internal “DevSecOps Maturity Model” if you will that you can take to individual product and platform teams, and evaluate processes and culture. Don’t include surveys about “are you using this tool and is it configured in this way” as that should be separate to this imo.
Tools
Im writing this separately as feel it is subjective and often if youre Enterprise youll need to go through a procurement / evaluation phase. This is a great opportunity to have one of your in house SMEs evaluate the tools through a Proof of Concept, and, importantly, identify which tool integrates best within YOUR environment and processes.
One note I’ll make on tooling - as long as it has the relevant features you need, performs well and isn’t just a bunch of marketing hype - the tool should not be your focus. Process and Culture around the Tool is much more important.
-
Infrastructure as Code (IaC) Security Tools: Tools like Checkov (Now part of Palo Alto Prisma but luckily still sourced) are at the top of my list. If youre using Terraform, imo Terraform Sentinel is pretty good but does tie you to enterprise licensing.
-
Static Application Security Testing (SAST) Tools: There are so many. I like Snyk. Its paid for, but its quite nice: Providing IDE plugins, insight into particular vulnerabilities and code snippets from public Git repos where a similar / identical issue was fixed and how it was fixed. From experience using a few, Ive found that it doesnt really matter which one you go with as theyre all going to spit out false positives and its about how you can tune them.
-
One call out is that SAST overlaps linting and styling somewhat, and some tools i.e. sonarqube seem to do better on that front rather than actual code vulnerabilities (i.e. SQL Injection)
-
On Open Source SAST, honestly im not a big fan. I’ve tried so many, and whilst ofcourse it depends on the tool and the language, generally speaking SAST is somewhat difficult to get teams to adopt so you want to introduce something as frictionless as possible. If you drop in a tool that requires significant tuning and provides a lot of false positives out of the box, it’ll be hard to get adoption. Consider this whilst evaluating, and make sure you evaluate it at least based on your top 3 languages used.
- I personally do not like GitLab SAST as it uses open source tooling under the hood (see SAST analyzers | GitLab for a list) - doesn’t make sense to me to pay for something I can use for free.
- Contrast Security, Veracode, and Checkmarx are worth a look at.
- Dynamic Application Security Testing (DAST) Tools: DAST tools like OWASP ZAP, Burp Suite, and Acunetix (Now Invicti which is awesome) fit this category.
Now… I have something to say here on DAST, which also relates to SAST.
-
Firstly, if youre deploying multiple times per day, you can’t rely on a long running DAST scan as part of your regular CICD pipeline. It makes more sense to have it scheduled nightly or weekly outside of your application CICD, and potentially some integrated quality gates here for promotion of apps between environments.
-
Secondly, tools like OWASP ZAP out of the box don’t “just work”. Even just to measure the OWASP Top 10, or the OWASP API Security Top 10, there is further config to be done. Fortunately there are modules for OWASP ZAP pre-written for most stuff, but it’s still further config so - it’s important to manage your expectations going into DAST in advance of just selecting it as a tool. It’s something that should be properly PoC’d out with a product team and have their buy in early as it will be difficult to roll out otherwise.
A final note for you to review. There was some great discussion on a LI thread I saw recently about DAST: Abhay Bhargav on LinkedIn: 🪦 "DAST is dead" Well, it depends on who you ask. The answers, as… | 34 comments
- Thirdly… IAST! WHAT IS THIS? Is this the future of SAST and DAST?
I’d check out Jeff Williams, CTO and Cofounder of Contrast Security (who in my opinion are the market leaders in IAST) and what he has to say about IAST - let him convince you and do your own evaluation. IMO, IAST makes much more sense in pipelines where you practice Continuous Deployment and deploy multiple times per day. Built into the software itsself, it’s giving the same advantages of SAST and DAST but from the inside out, rather than outside in approach 
- Container Security Tools: Tools like Docker Security Scanning (Integration with Snyk), Aqua Securitys Trivy and Clair are the cheapest tools to get started with. Trivy is probably my pick as its a bit of a swiss army knife. If you are enterprise sized, Palo Alto acquired Twistlock and is now part of Prisma, and Aqua Security also have an enterprise offering. Sysdig is worth another mention. There are two main things to think about here - Image Scanning, and RASP / runtime protection.
Anyway I think that’s enough for now… And we haven’t even started talking about supply chain security, provenance or attestation w
2 Likes