This cheat sheet is possible thanks to Siddharth Barahalikar’s course on Udemy

DevSecOps integrates security into software development, testing, and delivery processes. The idea behind DevSecOps is that security is everyone's responsibility, and it comes into play from the moment you start building software. Everyone is responsible for DevSecOps

The problem that DevSecOps solves is that the team can maintain velocity (ex: rate of software delivery) while improving software quality with a security mindset without introducing more risks to the product for the end users

Main idea

DevSecOps!=DevOps, its an extension fro security practices where security is integrated into every step of the software development cycle including the CI/CD pipelines.

DevSecOps Pipeline

Applications of DevSecOps

• Secure Code Review
  • If for example a developer mistakenly implemented a weak password password policy which puts user data at risk from potential brute force or dictionary attacks
• Static Analysis Security Testing (SAST)
  • Automated tool that scans the code and informs the developer if any vulnerabilities are found (improper error handling, insecure data storage, code smells, etc..)
  • Can scan an application before the code is compiled
• Dynamic Analysis Security Testing (DAST)
  • Automated tool that looks at the application from the outside, triggered each time a new feature is deployed to a staging environment. This ensures that potential vulnerabilities, such as cross-site scripting or SQL injection flaws, are identified and addressed in real-time
  • DAST has no access to the application’s source code, it detects vulnerabilities by attacking the application externally
  • Top risks that can be detected such as: cross-site scripting, SQL injection or command injection, path traversal, insecure server configuration
  • Not highly scalable (because its relied on written test cases) and sometimes slow scans, but its technology independent and can identify configuration issues
• Infrastructure as Code Security
  • Every configuration change triggers an automated security scan to analyze issues such as unencrypted storage, access controls, etc.. then informs the developer
• Container Scanning or Container Security Analysis (CSA)
  • The image could include an outdated library with known vulnerabilities in the Dockerfile or which components making up the base operating system and any software loaded onto it
• Software Composition Analysis (SCA)
  • An application security methodology for managing open source components
  • Scans for known vulnerabilities in the code’s open-source or third party libraries
  • More about SCA in this article

There’s also a good article talking about the difference between SAST and DAST

Best practices