Zero trust policies for software releases could be key

Today’s integrated DevOps methodology offers businesses the promise of accelerating innovation by providing customers and employees with new application capabilities faster. However, this approach can also increase risks associated with cybercrime and the failure to comply with rapidly evolving privacy regulations. As a result, minimizing security risk during the development process is every bit as important as bringing new capabilities to market as quickly as possible. Effectively minimizing release risks by shifting left the responsibilities and enforcing zero trust policies can even help accelerate the release of new software by identifying security issues when they arise, so they can be more rapidly resolved, rather than identifying them during a separate security review.

Leading enterprises are tightly integrating Security into the DevOps process in a modern DevSecOps approach. The associated best practices, paired with an AI/ML-powered continuous delivery (CD) automation platform, can reduce risk and accelerate software releases.

The Critical Need for DevSecOps when integrating security into the SDLC

Risk in the software development lifecycle arises from multiple sources. Microservice architectures add complex networking requirements that increase the attack surface. Public cloud-based technologies and services, including databases, message brokers, service mesh, and virtualization, complicate network isolation, as each can be exposed to the public internet, increasing the attack surface and exposing additional vulnerabilities. The increasing use of open-source software for improved productivity brings its own challenges, as evidenced by the SolarWinds exploit. Increasing reliance on Kubernetes also raises security concerns because if one Kubernetes pod is breached due to any security issue, all the other pods can easily be attacked. Notable incidents include a breach that resulted in the exfiltration of 30GB of credit application data from Capital One and the planting of malicious images in the Docker hub, resulting in cryptojacked computer resources used to mine cryptocurrency.

Despite these increased risks, most organizations struggle to achieve higher collaboration between operations, product development, and security teams on ways to improve security. The security and compliance checks that are performed are typically conducted at the end of the DevOps cycle. This leads to unnecessary rework, release delays, and an increased possibility of vulnerabilities making it into production software. The lack of collaboration can also lead to a blame game when security and compliance failures occur. A security-conscious healthcare company had policies in place to review software security before promoting it to production. However, an audit found that insecure software frequently made it into production because a feature or patch needed to be deployed urgently, and the manual security reviews were bypassed. A secure delivery process must support continuous feedback across the teams in the delivery process to address gaps and improve security posture.

However, just improving collaboration between operations, security, and development teams aren’t enough. To combat these evolving risks, the security team needs to learn about and keep up with all the underlying technologies and how to identify threats. Checks for known threats must then be conducted during the development process and development teams must respond to threats as they are identified rather than at the end of the software development process. A fortune 500 company wanted to add a feature, and the development team chose a library from an open-source repository to deliver the feature faster. After six months of development, when the product was ready for a beta release, vulnerabilities in the library were identified that would take more than three months to address and an alternative library could have created a more secure system with a similar feature set. Performing security checks as part of the development process would have saved months of product development time.

"Zero trust policies for software releases could be key"

The best solution for minimizing security risks during the development process is automation. The goal of DevSecOps is to integrate and automate security and compliance testing throughout the development pipeline so vulnerabilities are identified as early as possible without compromising the speed and agility of the development teams. Accomplishing this goal requires technology and processes that support three pillars:

•    Providing visibility into security issues throughout the software delivery workflow
•    Identifying security issues as early as possible in the development cycle
•    Enabling the automatic enforcement of security policies throughout the workflow

Providing visibility into security issues throughout the delivery pipeline

Every application should go through a comprehensive list of security tests, including static application security test (SAST), dynamic application security test (DAST), fuzzy testing, dependency scanning, binary scanning, license compliance, and secret detection. The security team, developers, and project managers should all have access to the results of these security scans. This is the only way stakeholders can quickly identify security risks that require halting the development workflow, so developers can immediately iterate until the vulnerabilities are resolved. An AI/ML-powered CD platform can provide a scalable orchestration layer that integrates and automates continuous security checks in the development workflow.

For example, an orchestration layer based on open-source Spinnaker or Argo CD can integrate with any SAST/DAST software security tools to ensure security checks are not bypassed during the delivery process. The orchestration solution can then provide the results in a shared approval dashboard.

Identifying security issues as early as possible in the development cycle

The earlier that risks can be detected and identified in the software delivery cycle, the faster and easier it is to mitigate them. Without automation, however, this risk assessment requires a very time-consuming manual review of a large number of logs and metrics produced in the build, test, deploy, and production stages.

For example, in the development of a service, a developer introduced falling back to HTTP in case of failure of the HTTPS connection to a remote service. This was a violation of policy and could expose private data. However, the issue was not discovered until a gateway was altered to stop HTTP traffic from going through, at which point the application stopped working. This issue should have been caught earlier in the test cycle when the HTTPS connection was replaced with HTTP, eliminating potential breaches and countless hours of troubleshooting.

By contrast, a CD automation platform can scan through thousands of build and test case logs, and identify the root cause of a failure or risk in an instant. Error events can also be filtered through predefined or user-defined categories to reduce analysis time. Similarly, such a platform can leverage ML to analyze metrics data from monitoring tools to instantly perform quality and performance checks in the deployment and production stages.

Automatically enforcing security policies throughout the delivery pipeline

True application security requires more than minimizing security risks in application code. It also includes ensuring compliance with internal policies (e.g., a release cannot be deployed until all testing is completed) and regulatory requirements, such as those related to reducing the risk of breaches and data privacy violations. Examples abound of major corporations that were breached, resulting in massive disruptions for major organizations including Facebook, Alibaba, LinkedIn, Accenture, and Marriott International.

In addition to the growing number of requirements, policies may need to change based on region. For example, it may be a violation of privacy regulations to deploy a particular application in a specific region. Further, all these regulatory requirements are constantly evolving, so security and compliance managers must be able to easily define and update policies in a way that does not hinder developer efficiency. This has led to the adoption and growth of Open Policy Agent (OPA), which provides a unified authorization method for CI/CD pipelines, Kubernetes, and Terraform.

There must also be a mechanism for enforcing compliance at every stage of the software delivery process. A CD platform that leverages AI and machine learning can offer teams the ability to apply policies (e.g., leveraging OPA), support continuous governance and compliance checks, and continuously improve the system’s ability to quantify release risk.

Conclusion

For many organizations, the idea of DevSecOps conjures fears of a new layer of bureaucracy that will cause confusion and frustration and slow the development process. But by implementing DevSecOps methodology with intelligent CD automation tools, it’s possible to decrease risks and ensure compliance while increasing development velocity. In fact, by making it faster and easier to identify and eliminate security risks, developer productivity can increase while eliminating the tensions and blame game that often exists between the security and development teams.