9 security points to consider throughout your application lifecycle

To understand why, let’s take a look at the working relationship between development and operations. As the working relationships between the two teams grew closer (through DevOps principles, practices and tooling), the speed of software delivery dramatically increased. Teams have moved from releasing software updates a few times a year to doing so many times a week or even many times a day. This increased capability addresses a need for organizations to respond to market pressure and customer demand, but it can increase risk if the security teams and tooling do not keep up with the pace of delivery.

The need to apply security principles throughout the software delivery lifecycle has become very clear, and is the core tenet of the DevSecOps movement: to add security to all elements of the existing DevOps practice without impacting delivery speed. In environments that don’t employ a DevSecOps mindset, security controls often are applied only after the application has been deployed—increasing the risk to the organization and adding significant rework and delay to developer productivity.

To understand the challenge, these are nine security points tech leaders should consider throughout the application lifecycle:

• Security professionals do not develop and write functional application code on a daily basis.

• Developers do not follow or respond to security-related incidents or events on a daily basis.

• Developers and security professionals have a different set of priorities, a different set of tools, and often a different organizational reporting structure.

• Communication between teams is often “ticket-based,” which increases the risk of miscommunication, gaps in coverage and rework.

• On-premises, cloud and hybrid cloud infrastructures are generally presumed to be secured automatically, which is often not the case.

• Applications are growing increasingly complex as they transition from monolith to microservices, which increases the exposure of each component to attack.

• Developers are increasingly authoring infrastructure-related components that are massively complex (such as Kubernetes manifests or other infrastructure-as-code languages).

• Operations and security professionals run and protect hundreds to thousands of applications and do not have intimate working knowledge of each application’s security requirements.

• The number of developers far exceeds that of security engineers by 100 to 1 (in a study done by Gene Kim), and developers may not have a good grasp of security practices. Organizations should strongly consider educating the entire technology department around security.

These challenges are daunting for any organization to solve, requiring investment in time, education, tooling and cultural change. However, with many years of investment in DevOps principles under the belt for most organizations, these challenges aren’t new.

As Figure 1 shows, each area of an organization’s DevOps practice can integrate security into its existing design, deployment and operational tooling and practices by starting with three things: a shift-left mindset, security by design and zero-trust architecture. 

• Shift-left mindset: Think about and identify security issues early in the software development process, based on the principle that the sooner a vulnerability is identified, the cheaper it is to remediate.

• Security by design: Build on the shift-left practice by assuring that security features are built into the application or service at the design stage, rather than bolted on later.

• Zero-trust architecture: Assume that hackers can access all parts of the network (internal and external) and put in place mechanisms to thwart this intrusion, such as data encryption, identity-based access controls and minimal service exposure.

Figure 1. How Cybersecurity Applies Across Artifacts, Pipeline, and Target

These concepts are all very healthy for an organization to adopt, but to keep pace with the demands of rapid software releases and increasingly complex infrastructure, a heavy investment in security tooling and automation is necessary. 

While the tooling and automation investment needs to happen through all stages of the software development lifecycle, the more we invest in tooling that is closer to the developer (shifting left), the greater value we see in both risk reduction and increased speed of delivery. 

In short, supporting your developers with the means to identify security risks earlier in the process means supporting your organization’s long-term ROI.

To learn more about Key Criteria for Evaluating DevSecOps Tools, grab your own copy of this insightful report in partnership with GigaOm.

GigaOm democratizes access to strategic, engineering-led technology research. We enable businesses to innovate at the speed of the market by helping them to grasp new technologies, upskill teams, and provide strategic sales training and advisory services to navigate opportunities and challenges. The GigaOm e-learning platform changes the game by unlocking deep technical insight and making upskilling teams accessible to all.