What Does DevSecOps Stand For ?
DevSecOps is an acronym for three words that are Development , Security and Operations. DevSecOps is a necessary evolution that ingrains security at every level and makes everyone accountable.
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 the software lifecycle agile and responsive.
Security always worked in a silo. Earlier, when software development used the waterfall development model, it was normal to have security and compliance checks done at the end of the process. But with Agile and a faster and frequent software delivery cycle, those checks at the end make the DevOps process rigid and slow.
Be it highly regulated banking applications or online e-commerce sites, maintaining 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 include security as an integral part of DevOps processes.
A lot of security and compliance checks have to be done. Examples include:
-
- Vulnerable new libraries,
- Expired license,
- Exposed passwords,
- Misconfigured Kubernetes components,
- Adherence to organizational standards, etc.
The security and compliance team will analyze and look for any issues in the application. And this will take some time, maybe days. There might be many requests pending from the streamlined software delivery process (using CI/CD pipeline), and security checks right before the release could delay the delivery process.
So the adopting the idea of DevSecOps i.e, to integrate security early in the continuous delivery process and remove vulnerabilities, without hampering the velocity of software release.
Why DevSecOps is Important?
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 competitive advantage. However, there is only one downside of microservice- 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. And those microservices by nature expose 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 more surface area for a security attack. Microservices use containers, which 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).
- Using microservices, containers, cloud platforms, and Kubernetes makes applications prone to attack and ensconce security as a fundamental problem in IT organizations.
On the other hand, security teams are not well equipped to handle containerized application. They need to learn and understand the security implications with all the new technologies (microservice, containers, Kubernetes, etc.) in order to identify the issues. And there is steep learning curve. Thus, it’s important to make security shift left in CI/CD pipeline, i.e. to practice DevSecOps.
Three essential considerations to achieve DevSecOps
Security cannot be treated as siloed operations; it has to be a shared operation between the product team and the security team. To mitigate software risks and frequently deploy software into production, integration of security best practices into all stages of deployment is essential. Refer to the image below: is
We propose three essential items 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 as 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 security team uses various tools (mentioned below) to understand the security posture of the project or the group of tasks.
- SAST- Sonarqube or Bandit or HCL AppScan, etc..
- DAST- HCL Appscan, OWASP ZAP
- Container Image scanning ( Kubernetes or VM Scanning)- Aquasec
The security team developers and project managers should have common access to the security scan reports containing the issues and vulnerabilities. These tools have to be part of the delivery pipeline so that managers can view the information and make decisions to halt the deployment pipeline in case of genuine and critical errors. This way, developers can immediately iterate the merge request (without any context switch) until all the vulnerabilities are resolved.
Let’s see some examples on how DevSecOps pipelines are robust and secure:
Potential vulnerabilities like SQL injection vector are found during a static application security test (SAST) to scan application source code ( like JSP, XML, CSS, etc.). In this case, a delivery pipeline has to be failed automatically.
Or, during Dynamic Application Security Testing (DAST), the security tool scans dependency and finds the application is using older versions of libraries. In this case, a delivery pipeline has to be failed automatically.
How to leverage OpsMx Enterprise for Spinnaker (OES) for integrating security
OES, an ML-based continuous delivery platform, offers continuous security i.e. integrating security checks in the delivery automation. OES can integrate with any SAST (like SonarQube) or DAST tools (like Aquawave and HCL App Scanner), ensure security checks are not bypassed during the delivery process and provide the results in the approval dashboard. With consolidated information such as Jenkin builds, JIRA tickets, and security scan results, project managers can take a call to stop the pipeline from progressing. They can notify developers to work on the issue or can allow the deployment by dismissing false positives. ( refer to the below images)
Spinnaker pipeline with SonarQube scanning stage
Fig 2A: Spinnaker pipeline with SonarQube scanning stage
OES Approval dashboard with Security scanning info
2B : OES Approval dashboard with Security scanning info
OES can also be orchestrated to take automated decisions to (dis)approve a delivery pipeline from execution in case of errors from security tools.
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. For example, using log analysis, OES can identify architectural regression by identifying changes in communication patterns, ie. if there are changes to communication between services in terms of talking to new services or using different protocols than before ( say HTTP rather than HTTPS).
Or, OES can lookout for patterns of AWS access keys in logs to highlight exposed passwords.
If Continuous Delivery can deploy changes to production every few minutes, any manual task like quality regression from logs will not be able to keep up.
How to leverage OpsMx Enterprise for Spinnaker (OES) for identifying risk
OES does risk assessment of releases in all stages of software delivery. Automatically scanning through thousands of build and test case logs, OES can point to the root cause of a failure in an instant.
Detailed log views in OES provide instant access to important log events, eliminating the need to sift through massive log files. OES summarizes duplicate events and clusters-related events to enhance visibility and reduce clutter. The error events can be filtered through predefined or user-defined categories to reduce analysis time.
Similarly, OES can perform quality and performance checks in deploy and production stages and determine the risk of release by applying ML techniques to metrics data from monitoring tools.
Fig 3A: Risk assessment by OpsMx Enterprise for Spinnaker
With OES, you can avoid high-ceremony releases into production and even stop the CD pipeline from progressing in the early stages of software delivery, saving time and cost.
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.
How to leverage OpsMx Enterprise for Spinnaker (OES) for security and compliance in DevOps
OpsMx Enterprise for Spinnaker offers Continuous Compliance to define security policies in your software delivery pipeline. As a result, you can ensure your DevOps process complies with organization governance and rules while shipping your code, upgrades, and application to production.
Fig 4A: Defining policies in OpsMx Enterprise for Spinnaker
OES allows security and compliance managers to create policies and enforce them in each stage of the software lifecycle. Compliance managers can:
- Create policies to check various software release parameters and deployment conditions before/during the execution of the delivery pipeline.
- Edit, delete, and modify policies.
- Audit and investigate policy violations, failed compliance checks, application names, etc.
Watch a detailed demo on compliance and audit.
Try OpsMx Enterprise for Spinnaker(OES)- an ML-based CD Platform for DevSecOps
Security might look like a deviation from the usual DevOps cycle. Still, it is highly essential to make it a part of the DevOps pipeline to avoid service disruption, security breaches, cyberattacks, and compliance with privacy regulations. In addition, continuous delivery is incomplete without security and risk mitigation strategies.
OpsMx offers an intelligent and highly secured platform for DevOps teams to incorporate security in the early stages of software delivery.
By the way, other security features that come ootb in our CD platform are:
-
- Authentication and Authorization that follows all security protocols like LDAP, SAML, and RBAC. Read More
- Secure communication between external services with Spinnaker and data encryption using mTLS (mutual Transport Level Security) and X509 (public-key) certificates-based authentication. Read more
- Enterprise-level secret management, by storing sensitive information and secrets (e.g., Jenkins passwords, k8s kubeconfig files, tokens, etc.) in Vault, Git, S3. Read more.
OpsMx Enterprise for Spinnaker is now available in SaaS. Get started with your DevSecOps journey today
0 Comments