Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to move beyond shift left, to shift 360

Kirsten Newcomer Senior Principal Product Manager, Red Hat
Long exposure nightime photograph of burning steel wool swung in an infinity pattern

Taking full advantage of DevOps means integrating security into the complete lifecycle of your apps. In this model, called DevSecOps, companies address security as early in the development cycle as possible—an approach also known as "shifting left." In today's zero-day environment, however, shifting left isn't enough.

Organizations need to think beyond shifting left—to shifting 360.

Shifting 360 means closing the DevSecOps infinite loop by ensuring that security information continuously flows among all team members—dev, ops, and security. This will ensure that analysis during development informs security policies for production and that issues discovered in production inform future development.

Shifting 360 means that security is the job of every employee in the organization and that nothing is said, done, or thought without a security context. Security must be the priority across the organization and within every business process. 

As we've seen all too well with Log4Shell and Spring4Shell, a single vulnerability can have profound and seemingly endless effects on an organization and its partners. The critical zero-day security flaw in the Log4j logging library—which has been challenging to completely identify and remediate because it's so widely used—was no one's fault. However, determining where it was running, before the bad guys could take advantage, was everybody's business.

How to improve your security posture

Companies can implement a number of products and services to improve their security posture, and threats and security requirements will change over time. In the meantime, there are three things companies should be thinking about right now to help ensure that they are addressing security from all possible angles.

Zero trust

The increasing adoption of cloud, and the development of cloud-native applications, means that the traditional network perimeter-based security model no longer offers adequate protection.

The foundations of zero trust are "deny by default" and "verify all." The former addresses the decoupling of trust from location, and the latter requires that every request for access to a resource is dynamically validated using identity management and risk-based, context-aware access controls.

It’s important to understand that zero trust is a model, not a product. Organizations should inventory their infrastructure to determine what platforms and platform features—for example, identify management and Kubernetes network policies—support the zero-trust model and what needs to be added to fully deliver on zero trust's promise.

Software bills of materials

In the wake of SolarWinds and other attacks that compromised the personal data of untold numbers of people, the Biden administration called for a software bill of materials (SBOM) as part of its executive order on improving the nation's cybersecurity.

The emergence of the Log4j and Spring Framework vulnerabilities underscores the need to develop and maintain an inventory of components included in the software that businesses deploy and manage. SBOMs make this work easier.

When you have an inventory not only of what's deployed but also of what's inside what’s deployed, you can begin to effectively query for components with newly discovered vulnerabilities such as Log4Shell and Spring4Shell. Cloud-native computing makes it more challenging to develop SBOMs because of all of the moving parts of the model.

Until SBOMs are more widely delivered, organizations consuming external code will need to leverage tools designed to produce SBOMs through analysis of software packages, using this information as input to an SBOM for the applications they develop and deploy.

Cross-functional security teams

In the DevSecOps model, application and infrastructure security are tightly woven into all DevOps initiatives. Breaking down silos between developers, operations, and security teams is key to strengthening overall security and limiting the threat landscape.

However, shifting 360 requires a top-down effort and executive commitment to ensure that employees across the organization are trained and engaged in the job of keeping the company secure. It goes beyond checking off a box with a "lunch and learn" to developing a culture in which security expertise is embedded across the organization, ensuring that security is baked into new products and services from inception throughout the application lifecycle.

Culture is reinforced by measurement; it’s important to measure the desired behavior, such as measuring time to discovery and remediation, and reward improvements.

Move your security arc

Shifting 360 is all about creating a culture in which security is the priority across the organization and within every business process. Organizations must align products, processes, and people with this purpose while considering foundational practices such as zero trust, development (and maintenance) of software bills of materials, and embedding security experts into cross-functional teams.

Keep learning

Read more articles about: App Dev & TestingDevOps