Understanding DevSecOps the Easy way

10 min readMar 13, 2024

Indeed, the image above captures reality. For many organizations, DevOps and Security are never in the same boat. Some may be confused about ‘which security mechanism to go with’ while others may have a solution but are overloaded with false positives. . Above all, some believe that the only thing that DevSecOps involves is VAPT evaluation.… Well definitely not

So lets understand the basic flow :

1.Business Requirement

Understanding the business requirement is the starting point for your DevSecOps model. The following things are the basic inputs required to understand the business requirement;

Budget — most organization are low on budget when it comes to security. Depending on the budget we can choose the tools (Paid 0r Open Source)
Compliance — determines what exactly the expectations are from the model. For example, if an application has to be CIS compliant then all the Security mechanism in your model must comply to the same. or what manual security checks are required and which are expected in CI/CD.
Infrastructure — A critical part in the process, it is necessary to determine what are the environments (Dev, sit, uat) provisioned for the application & the environment which can be used for the security testing. This helps in determining the computation availability for SecOps

· Feasibility — Depending on the above 3 inputs we can design a feasible DevSecOps model as per the business requirement. At this point if there are any road blocks, we can work with the business team to find the best feasible solutions. For eg: An open-source tool for SAST is not fitting in the company’s privacy policy. They do not have budget for buying a paid toll but they also need Static Application Security Test (SAST) in the CI (Continuous Integration)

· Maintenance — DevSecOps solution requires some security skilled manpower to get the best out of it. Having a maintenance plan is must if you want a successful and effective DevSecOps Model. For eg: A company which is low on budget and cannot hire a separate resource should make sure that they have someone from the team with a ‘T’ shaped knowledge of Security , Devops and Infrastructure who handles the maintenance along with implementation.

2. Model Design

Once you have the business requirements , we can proceed for the model design .

DevSecOps Model consists of two elements :

Security Mechanism — For example (SAST,DAST,SCA).
DevOps Phase — As the name suggests , it is the phase of Devops pipeline where we integrate the relevant security mechanisms.

For eg: The expectation from the desired model is to invest more towards the shift left ( adding security in early stages of SDLC) . Also , they want to avoid any security fixes post the TEST phase (maybe they do not have budget for VAPT and Cloud Security). In this scenario the best model we can design is to have controls in Build and Test phase

The highlighted security mechanisms can be removed from the model . However a question will definitely arise in your mind — · LEAVING THEM OUT WILL LEAD TO SECURITY FLAWS UNCOVERED AND UNDETECTED, ISN’T IT?

The answer is NO . Well , this brings in picture a Very critical concept . ‘Defense in Depth’

So I assume you had a look at the Defense in depth article , using the same concept we can

catch Cloud and Infrastructure related vulnerabilities in the BUILD phase via the IAC mechanism .
Make sure Shift left mechanisms are catching all loopholes and remediations are pushed in staging environment .

3.Tool selection

Okay now with some confidence and a Clear picture of our DevSecOps model we move towards choosing the tools .

You should be very careful while selecting which tool to integrate. There are scenarios where organizations go with a different tool for each security mechanisms . This increases the manpower requirement and becomes difficult to manage.

Try to select a tool which can offer as many security mechanisms .

Sonarqube for SAST
Snyk for container security
Mend for SCA
OWASP ZAP for DAST
The above 4 mechanisms can be cover by a single too . For eg : Checkmarx

Below are the minimum requirements for tools to qualify for a place in DevSecOps pipeline.

1.Fits in the budget

2.Easy to integrate in SDLC

3.Should not overwhelm with false positives

4.Integration with ticketing tool

5.Multiple Compliance options

6.Integration with vulnerability management tools

7.Comprehensive vulnerability reports along with remediation plans

8. Capability to whitelist/mute the false positive

Following is a list of top DevSecOps tool which you can refer .

4. Automation Management

Now you have a model with qualified tools . Let’s move forward . .

You need to segregate the security mechanisms as

CI/CD— which are triggered automatically in their respective phase when the Devops pipeline runs
Non CI/CD— which cannot be triggered along with the Devops pipeline and needs manual intervention

After segregation ,

→ Design ci/cd trigger for relevant security mechanisms .

Now lets elaborate the CI/CD triggers for both phases and understand the significance each of them hold for a successful DevSecOps framework.

Code and Build -
During these phase the code which you are pushing to the Release branch can be checked for vulnerabilities by triggering the security Pipelines .
If any pipeline fails your PR will be blocked until resolved.
This way we are shifting left for security and making sure vulnerable code is not trauma deployed.
In order to avoid unnecessary blocking, make sure you are setting the condition for failure as per vulnerability threshold very carefully .

########################################################

what we achieved ? A security compliant code . All this even without deploying the application and thus eliminating the trauma of — — identifying vulnerabilities in testing/staging environment → Fixing the code → rebuild → retest → redeploy

In the above example :

If you do not catch an ‘Input Validation’ vulnerability via SAST in Code phase , the vulnerable piece of code will become a deployment and will be flagged by security mechanisms like DAST/IAST/RASP
Thus, you need to fix the piece of code — again build — again test — again deploy. TRAUMA ! Frustration !
However , if you catch it early in the SDLC ( using SAST) you are definitely saved from such trauma.
This pretty much sums up the importance of shifting left in SDLC

##########################################################

Release -
As discussed above, we saw shifting left eliminates the vulnerabilities before it reaches the deployments .
However, this does not rules out the requirement for a security mechanism in release phase.
There is a list of vulnerabilities which can be identified only during the program runtime .
For this , you need to place dynamic testing security mechanisms which stimulates an outside attacker’s perspective. For eg : DAST , IAST
Dynamic testing is useful for detecting misconfiguration in servers or databases that affect web application security during runtime.
It can also catch authentication and encryption issues allowing unauthorized access, which Static testing (SAST) cannot.
Also, Dynamic testing can test other API or web services your web application connects to, in addition to IT infrastructure resources like networking and data storage.
So, it is valuable for testing the entire IT environment where your application or web services operate.

## Thus adding security mechanism in CI/CD triggers ensures that every change in the code & every deployment goes through security checks ##

→ For manual mechanisms you need to implement them during their respective phase

For eg :

Security Architecture review would be done manually during the plan phase and cannot be added in the CI/CD .
Similarly , VAPT also cannot fit in CI/CD triggers and has to be performed once the application is deployed to staging environment .

5. Vulnerability management

Vulnerability Management is the ongoing, regular process of identifying, assessing, reporting on, managing and remediating security vulnerabilities across endpoints, workloads, and systems.

This definition greatly presents that Vulnerability Management as many other cyber security related processes is not a one-time task but is an ongoing process.
The most decisive part for a successful DevSecOps model is Vulnerability Management . Do not hesitate to go that extra mile if required to make this perfect.

Why vuln management ?
Once we integrate the security tools, we will get a number of security alerts for the given microservices .
However, remediating everything everywhere takes up a lot of effort and time . This will hamper the product delivery .
Thus , you need to prioritize the high risk vulnerabilities and remediate them accordingly.

How do you do that ?

There are 2 ways :

You can manually asses your architecture and determine high risk vulnerabilities
You can use a tool which will take inputs from the security tools which you use in your DevSecOps model and help you prioritize the vulnerabilities .

→ Manual approach :

Consider the following architecture

Step 1 : Determine the microservices/cloud assets which are exposed to internet or act as an entry point into the application

Internet exposure means a potential attack surface is open for the attackers
Determine these attack surfaces and list them out
In our example it is Microservice BE and FE

Step 2: Map the vulnerabilities for the listed attack surfaces

From all the tools , gather the flagged vulnerabilities and align them with their respective attack surfaces.

Step 3: Train your mind that high CVSS score is not a high risk vulnerability

High CVSS for a vulnerability is definitely a red flag.
But this alone cannot decide the Risk rating for the same
Risk = likelihood ( of the vulnerability to be exploited ) * impact ( the vulnerability can cause if exploited)

For eg : You have a RCE vulnerability (CVSS 9+) for a microservice ‘FC’ .
If exploited , the vulnerability can lead to a reverse shell which can lead to complete compromise of the microservice. Impact is HIGH
However that microservice ‘FC’ is not exposed to the outside world and communicates with other assets/services on internal network.
This way no attacker can reach microservice ‘FC’ ( unless he penetrates in by some other way and moves laterally to microservice ‘FC’ ) . likelihood is LOW

Thus , even after having a CVSS score on the higher side the risk rating is low .

Step 4: Remediate the vulnerabilities

Now you have a prioritized list of vulnerabilities which can be remediated accordingly
Thus , risk assessment makes sure to save your time and invest the efforts in patching the high risk areas of your application

→ Automated approach :

If you have a big infrastructure, manual approach might be a tricky thing to achieve
In this case , an automated tool would come to the rescue

A classic example for automated Vulnerability management is DefectDojo

6. Product Delivery

Though adding security in the SDLC is beneficial , it should not become a blocker for the product delivery.
Remember the following things for smooth delivery :

Set the failure threshold for DevSecOps pipelines carefully so that it does not keeps on failing for not so serious Vulnerability score .
Make sure the vulnerabilities detected by security mechanisms in CI/CD triggers can be easily whitelisted/muted if not a high risk .
Have a bypass plan ready if any DevSecOps pipeline in CI/CD trigger is failing and not letting the Pull Request / Deployment to go through & a feature has to be deployed immediately by developers in testing environment . You may later revisit this part , get it fixed and again redeploy to testing/staging environments before the code goes all the way to production .
Most vulnerabilities will be fixed in CI/CD itself . But if you observe closely there are other security mechanisms in TEST/RELEASE phase which may point out vulnerabilities which are then.. remediated-> hardened version deployed to test env → tested → hardened version deployed to staging env → tested → hardened version deployed to production env.
Make sure the remediation plans aligns with the product release dates and always keep a buffer for testing the deployed hardened version . This will give you a window for fixing unexpected issues and will make sure security changes do not act as blocker for product delivery

I hope this helped you to clear your misconception with DevSecOps if any. In further posts we will understand each security mechanisms and its implementation in real world .