DevSecOps notes!
I spent the last three months reading the Agile Application Security book, book, which helped to learn more about how to:
- Add security practices to each stage of the existing SDLC.
- Integrate security with planning, requirements, design, and at the code level.
- Implement regulatory compliance in an agile or DevOps environment.
- Build an effective security program through a culture of empathy, openness, transparency, and collaboration.
The software development area is changing every day, and it keeps accelerating. Therefore, The security pioneers should also change the way how to operate.
Integrating security in each stage of your existing development lifecycle requires a good plan and a well-documented study on your current environment setup.
Most organizations face a slowdown issue when it comes to executing security tasks in the SDLC workflow, and the main problem is the absence of Automation.
Automation will play a key role in enabling application security to sustain the speed of DevOps.
What is DevSecOps?
Before I say anything, I'd like to mention that DevSecOps is not a one-person job; What you see on LinkedIn and other job listing websites is titles, nothing more than.
DevSecOps is a culture or a process where the whole team (Development and IT operations) works collaboratively to build, test, and release software in a more agile, secure, and iterative manner than the traditional software development process.
In a nutshell, DevSecOps means integrating security into every stage of the software development lifecycle. Some people refer to it as shift-left, which suggests moving critical testing practices earlier in the SDLC.
This is a mainly DevSecOps flow chart. On this basis, we can think that the most prominent feature of DevSecOps to SDL is Automation
Before moving further with Automation, we should divide the testing part into two sections:
1- White-box is the practice of testing the code running behind the scene. This kind of testing is typically executed in Static Application Security Testing (SAST), including analyzers and linters in the IDE. Scanning the codebase we write is not enough; nowadays, 80-90% of a software project is third-party code in the form of libraries and packages. Thus we need Software Composition Analysis (SCA) to detect software licenses, deprecated dependencies, and known vulnerabilities.
2- Black-box is another way of testing the application while it's running; it's also known as Dynamic Analysis security testing (DAST). Black box analysis occurs in real-time, finding security issues that an attacker could exploit while the application is running in the production server.
The most common issue we face as security engineers is a large number of the false positive rate, which we'd like to reduce by using both black-box and white-box test techniques.
Integrate Security tools in your build pipeline
If you'd like to integrate SAST/SCA/DAST/ or RASP tools, all you need to do is to choose a suitable CI/CD tool such as GitLab CI/CD, Jenkins or anything else.
Integrating those security tools is not enough to ensure that we have everything in place. The most challenging job is to review the tool's results and automate that process as well.
"It's much more useful to think of security as being a vector to follow rather than a point to be reached. Vectors have size and direction, and you should think about the direction you want to go in pursuit of security and how fast you'd like to chase it. However it's path you will continue to walk forever."
Top comments (0)