Understanding the shift from Traditional Security to DevSecOps and why every modern engineer should care.
For decades, security was treated as the last line of defense.
Developers team built the software. Operations team deployed it. Security team reviewed it.
Sounds logical — until release day arrives with dozens of vulnerabilities, failed compliance checks, and delayed deployments.
The problem wasn’t security itself. The problem was when security was introduced.
DevSecOps changes that by embedding security into the development lifecycle instead of bolting it on at the end.
Actually traditional security and DevSecOps , both solve the same problem security.
Both protects the business.
The only thing is each of them uses a different approach to find and resolve the security related issues.
One day I have created a new ec2 machine in AWS manually, Just follow the terminal and given the required things.
Its very simple, I didn’t take anyone’s help and created one.
The next day, DevSecOps team came to my mail and say that I have spinup an ec2 instance without CrowdStrike.
CrowdStrike is the package to be installed in our server to maintain the security so that to be protected from malware or ransomware.
That is the first time I am listening about the team. Before that we are having Security team, where they also does the same thing.
But the security team will come to me on end of quarter or end of years sometimes about the CrowdStrike issue.
Since security is very critical in the today’s world, reacting to the security concerns as soon as possible and resolving is more priority in DevSecOps.
This is one of the example, I have faced in my work place.
Some of the traditional security team responsibilities include :
- Vulnerability checks after developments
- Compliance validation before release
- Security reviews at the end of the delivery cycle
- Manual audits and approval gates
- Finding issues late in the process
Some of the DevSecOps team responsibilities include :
- Including Security in CI/CD pipelines
- Before deployments, detecting the secrets for the code.
- Testing Security automatically using SAST, DAST & dependency scanning
- Security checks of Container images and infrastructure code
- For every security related, team writes policies using Policy-as-Code.
- Build the platforms to perform continuous runtime monitoring and threat detection.
So simply Traditional Security focuses on catching the problems at the time of deployments , But DevSecOps focuses on preventing problems from being introduced.
Overall traditional Security is about the GATES, which is catching problems before software is released. Where as DevSecOps is about GUARDRAILS, prevent problems before introduced.
GATES are like :
A security checkpoint at an airport.
You have completed your journey and going out through the checkpoint, then you will be inspected. If there’s a problem, you’re stopped until it’s resolved.
Traditional Security works in a similar way. Developers build the application first, and security team reviews the security of the code at the development phase. If there are vulnerabilities or compliance issues, then the release is delayed until fixed.
GUARDRAILS are like :
Boundary features on mountains.
When you are on journey on the mountains, guardrails won’t stop you, they just provide you the right way to go, so that you won’t loose balance out of the mountain.
In the same way, DevSecOps checks are built in the development workflows using automations.
Every time if any developer writes code, builds an application, deploys infra; automatically tools which are configured previously will take care of scanning of vulnerabilities, secrets detection, any dependency checks and enforces the security policies to the issues found.
The DevSecOps approach is also called as Shift Left Approach.
Which means we are shifting the security related things before ( Left ) the deployment instead of fixing them post deployment.
Also fixing the vulnerabilities after deployment is more expensive compared to fixing them before.
By moving security earlier in the lifecycle, organizations can:
- Detects the vulnerabilities before deployment
- Reduces the remediation costs
- Releases software fastly to clients.
- Increase the productivity of the developer.
- Make very healthier collaboration among Devs, Security, Operations teams.
Then you may think like Traditional Security is not required in software development.
But no, It is still be a part of the cycle. But in an different way.
Such as :
- Governance Security
- Auditing Compliance works
- testings like Penetration testing
- Assessing the Risks
- Incident response in SRE level
- many more…
Definitely DevSecOps won’t remove traditional security practices in the software development.
Instead, They combinely works on the checks where they excel for there best.
Think of Traditional Security as a strategic approach for the process and DevSecOps as improvement in operational efforts.
My Thoughts :
The software industry has changed dramatically. Software Applications are deploying multiple times a day by multiple teams.
Infrastructure for cloud is created by IaC(Infrastructure as code). Traditional servers are replaced by Containers.
Then definitely Security also needs to be evolved with the changes happening in the industry.
Traditional Security focuses on finding problems before release.
DevSecOps focuses on preventing those problems from being introduced in the first place.
We have to make the engineering teams in such a way that they have to treat Security as a continuous and automated process in the development.
Whether you’re a student, an aspiring Cloud Engineer, a Security Engineer a DevOps Engineer, or a Platform Engineer, understanding DevSecOps is compulsory and required process.
Comments
Loading comments…