Devsecops Notes!: Agile Application Security Book

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

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'f like to chase it. However it's path you will continue to walk forever."

Bour Abdelhadi

You might also like