As its name suggests, DevSecOps is about adding security into the DevOps process.
For years, security tools and knowledge have been challenging to use for non-security developers. Yet, the situation has changed swiftly in the past few years.
Developers and DevOps Engineers can now leverage a handful of tools and simple processes to build hardened apps at a fast pace.
Let's explore the best practices to implement security in the DevOps process 👉
1. Automate all security scanning ⚙️
Security processes should be as seamless as possible. To do so, adopt automated tooling that runs inside the CI/CD, on pre-commit hooks, or periodically against staging environments.
Everything manual is at risk of getting forgotten, so make security checking a compulsory but perfectly straightforward process.
2. Check your Open Source dependencies 📦
Open Source has a lot of qualities, but it also means that you are importing code from mostly random internet people inside your project.
You can face two kinds of problems:
- The maintainer of a lib you use introduced a vulnerability in his package by mistake. Boom, you are vulnerable.
- Worst: one of the package's contributors introduced malicious code on purpose, and it hasn't been noticed by the maintainer. The malicious contributor hence has immediate access to your whole app.
This kind of attack unfortunately has increased by 650% in 2021.
By chance, a few handy tools exist to quickly check the packages you are using:
- trivy, a very user-friendly CLI tool that can find vulnerable dependencies in both OS and language-specific packages. I made a handy tutorial on how to use it for scanning docker images
- npm audit or yarn audit for nodejs packages
- safety for python (I also made a tutorial about it)
- And similar packages for all most commonly used languages
Most of those tools run in seconds and can be easily integrated into CI/CD, or git hooks.
3. Audit your code 👩💻
Vulnerabilities can also come from the very code you write.
For large applications, who knows if every user input is properly escaped? Who knows if all database calls are isolated from user-provided data?
Fortunately, a wild new open-source tool appeared for this purpose: semgrep. Inspired by grep, but for source code patterns, it can act as a very efficient and straightforward security linter.
I also made a tutorial on how to set it up in a few simple steps.
Note: CodeQL by Github and commercial software like SonarSource achieve the same purpose, but I find semgrep way handier.
4. Test your APIs. 🕸
End-to-end testing does not exist only for features. Its security pendant is called Dynamic Application Security Testing (DAST).
It involves tools that will interact with your API or web app through HTTP requests and try to find security bugs. Those generally run against staging or inside the CI/CD.
Project discovery's nuclei is a recent open-source project that achieves this very elegantly. And guess what? You can find here a fully-featured tutorial on how to set it up inside GitHub Actions. 😏
5. Avoid secrets leaks 🔐
Configuration secrets like API keys, database credentials, or SSH Keys often leak directly into git repositories.
While this is already a problem inside an organization, it is even worse if the repository is public.
6. Monitor, monitor, monitor 📈
Knowing what happens in your app at runtime is also a very important step towards having a safe production environment.
When 1000 requests with SQL injection attempts hit your API, you should get at least notified that something wrong is going on. Web applications firewalls are part of the solution, but thoughtful monitoring is even better.
Security monitoring tools are called SIEM, for Security Information and Event Management. (Yup, I try to avoid using specific jargon but this one is important!)
The Elastic Suite can be enriched with SIEM capabilities. They even provide examples in their repositories. Note that unfortunately, security monitoring is currently the least seamless DevSecOps task using only open source tools.
6. Train your team 🪑
Why is this section's emoji a chair? Because a common saying is the following:
"The problem lies between keyboard and chair"
It's especially true for cybersecurity, even among developers (including me!). But fortunately, developers are quick learners and you can raise awareness about this risk in a few steps:
- Ensure proper anti-phishing training
- Make sure everybody reads about the OWASP Top 10 Security List
- Encourage, if not enforce, 2-factor auth for everyone
7. Take a moment and think 🤔
Good tooling is a good start, but you can take it a step further.
Once you have implemented proper testing, training, and monitoring, just grab a pen (if you are in the office), or a shared markdown (if remote), and spend some time discussing:
- Which part of your application is critical?
- Which is more vulnerable?
- Who would be interested in attacking it?
- How they would do it?
And focus your security hardening on the parts where mitigation has the most return on investment.
This process is called Threat Modelling. It's slightly more advanced than the rest of this article, but I wanted to end up with some food for thought.
- Automate all the things
- Scan your dependencies with trivy
- Scan your code with semgrep
- Scan your web apps with nuclei
- Monitor what happens with elastic SIEM
- Take a coffee ☕️ and think about your threats to harden the right parts of your app.
Going further 🛰
Here are a few links to go further:
- TL;DR Sec, the security newsletter inspired by Dan's TL;DR
- Shehackspurple's great youtube channel on application security
- Awesome DevSecOps on GitHub
Wanna know more about Security? Check out our blog post "9 GraphQL Security Best Practices" and learn how to build safe GraphQL APIs.
Just like performance and reliability, security is a requirement to ship production-ready applications. But GraphQL just lacked the proper tooling so many teams just skipped security...
That's why we built Escape GraphQL Security Platform! Start monitoring the security of your endpoints today with a 14-day free trial