Contributed by Gopinath Rebala, CTO, OpsMx | Originally Published on opsmx.com
What is DevSecOps?
DevSecOps is about integrating security and compliance testing into the DevOps pipeline without compromising the speed and agility of continuous delivery. From a team perspective, the collaboration between IT security and the product team (including development and operations) must be increased to make software delivery agile, responsive, and secure.
In the past, the security team always worked in a silo. It was normal to have security and compliance checks done at the end of the process. But with DevOps and a faster and more frequent software delivery cycle, those checks at the end make the continuous delivery process rigid and slow.
Be it highly regulated banking applications or online e-commerce sites, maintaining a strong security posture has become important to the business. With the rise in ransomware, use of open-source software, and speed of delivery it is critical to embed security as an integral part of DevOps processes.
Many security and compliance checks need to be performed. Examples include scans for:
- Vulnerabilities when new libraries are added
- Incompatible Open Source licenses
- Unencrypted secrets
- Misconfigured network perimeter
- Adherence to organizational standards, etc.
The security and compliance team will analyze and look for any issues with the deployment architecture, ingress/egress, secrets management, vulnerability scans and delivery process. And this will take some time, maybe days. Performing security checks right before the release to production could delay the delivery process.
So organizations adopted the idea of DevSecOps, to integrate security early in the continuous delivery process and remove vulnerabilities, without hampering the velocity of software release.
Why is DevSecOps gaining popularity?
Modern organizations are migrating from monoliths to microservices, i.e. a series of loosely coupled services. Microservice architecture provides the ability to be agile, deploy code faster, and gain a competitive advantage. However, there is only one downside of microservices—they are not secure by design. Let us look at the following cases:
- Enterprises use a host of browser and mobile-based applications which follow microservice architecture. Increased number of microservices and by nature expose an increased number of APIs to communicate, which means much more attack surface for hackers.
- There are tons of services used on the microservices like databases, message brokers, service mesh, etc., which means even more applications and an increased variety of libraries with vulnerabilities for a security attack.
- Increased number of microservices further raises security concerns. For example, if one Kubernetes pod is breached due to any security issues, all other pods can also be easily attacked (also known as complex attack vectors).
Increased delivery velocity with microservices and particularly with container-based applications are prone to introduce vulnerabilities and make continuous security a fundamental problem in IT organizations.
Security teams need to learn and understand the security implications of all these new technologies to identify the issues. The learning curve becomes a significant bottleneck which is why it’s so important to automate security checks early on in the continuous delivery process, i.e. to practice DevSecOps.
Three essential considerations to implement DevSecOps
Security cannot be treated as siloed operations; it has to be a shared operation between the product team and the security team. Everyone is responsible for security. To mitigate software risks and frequently deploy software into production, integration of security best practices into all stages of deployment is essential.
We propose three essential considerations in DevSecOps to ensure your software and software delivery process is secured without its hampering speed, and they are:
- Integrating security as part of the CI/CD pipeline,
- Identifying the risk of a software release at each stage,
- Enforcing policies and automating organization compliance checks.
1. Integrating security a part of CI/CD Pipeline
Every application has to go through a list of security tests: static application security test (SAST), dynamic application security test(DAST), fuzz testing, dependency scanning, container scanning, license compliance, and secret detection.
The product team should have common access to the security scan reports containing the issues and vulnerabilities. These tools have to be part of the deployment pipeline so that managers can view the information and make decisions to halt the deployment in case of genuine and critical errors. This way, developers can immediately iterate the merge request until all the vulnerabilities are resolved. Open source continuous delivery tools like Spinnaker can be used to integrate security checks as a part of the delivery pipeline. You can integrate Spinnaker with SAST or DAST tools and create a security checks stage to automatically ensure security checks are not bypassed before the deployment stage.
2. Identifying the risk of a software release in the early stages of software delivery
The risk of a software release is mitigated when it is detected early in the delivery cycle, starting from the build process. However, risk assessment of releases requires a manual review of a large number of logs and metrics produced in the build, test, deploy, and production stages. This can be a manually intensive process and extremely time-consuming. You can use intelligent tools to traverse logs in each stage of software delivery to assess the risk of the software and highlight whether or not you should proceed with your pipeline or rollback.
3. Enforcing governance and compliance in the delivery pipeline
Application security does not only mean securing the application code-wise or monitoring its risks. It includes issues related to compliance and policies. There are new policies formed to comply with growing regulatory requirements for limiting breaches of application security. For e.g. policy to have no port other than 443 should be exposed or application service can be deployed only from the approved registry, or application cannot be deployed in certain regions. Apart from numerosity, the policy definition changes, say from one region to another, like, GDPR rules.
And security and compliance managers should define policies in time to improve compliance, security enforcement, and developer efficiency. They need a tool to protect the application and software delivery process at every stage. An example of a policy can be an application that cannot be considered for deployment if the testing is not completed. You can integrate open source Spinnaker with Open Policy Agent (OPA) to define security policies and rules in your SDLC process and enforce them in the pipelines. Consequently, you can ensure your DevOps process complies with organization governance and rules while shipping your code, upgrades, and application to production.
Conclusion
Older security models present a major constraint to continuous delivery as the later security is inserted into the process the longer it takes to expose and resolve any security exceptions or cease your speed of release process. Thus, it is highly essential to shift security left of a DevOps pipeline to avoid service disruption, security breaches, cyberattacks, and non-adherence to compliance with privacy regulations. To conclude we recommend that organizations who have achieved a fair amount of maturity in DevOps implementation, should now consider DevSecOps to improve their security posture.
