48% see security a major constraint on the ability to deliver software quickly

Artikel von:

28. Januar 2020

0 Min. Lesezeit

As teams and organizations rush to embed security throughout the software development life cycle (SDLC), challenges arise in many forms. In order to cope with the increased pace of software delivery and the scarcity of security resources available, organizations must face cultural, process, and tooling decisions –from shaping internal culture, to finding the right tools to embed in engineering workflows that enable and empower developers and minimize disruptive unplanned work.

With every data breach disclosed, organizations become more aware of the need to address security early on and throughout the SDLC to ensure customer privacy and assets, feature security, and delivery speed. To do it all well, DevSecOps must be driven by security, but powered by developers.

Executing well on DevOps is key to enabling DevSecOps

An organization is more likely to adopt security practices, the higher it lands on the DevOps evolution ladder. When organizations exhibit a strong level of DevOps tooling and culture adoption, they are well positioned to further enable security practices and DevSecOps. In the DevSecOps world, an organization relies on automation as a basis and empowers engineers throughout the organization to collaborate across different departments and take action to improve security.

We recently conducted a study on the adoption of DevOps and DevSecOps, with a key takeaway that 48% of respondents see security a major constraint on the ability to deliver software quickly.

Download PDF DevSecOps Insights 2020

Is security really a shared responsibility?

Everyone talks about security as a shared responsibility concept across the organization.Then why is it hard to turn to reality in so many cases? The Puppet State of DevOps report provides a cynical but not uncommon perspective on the matter: security concerns are often viewed as a means of averting a blame rather than measurably improve the overall security posture of an organization.

Moving on to another crucial question, is application security owned solely by the security team? From the Snyk State of Open Source Security report 2019 we learn that 81% of the respondents believe developers should actually own security, but that they aren't well-equipped to do so.

According to this survey, developers are the ones responsible for the security of their code and application.

How can we make them more successful? How can we empower these security champions to better integrate security into their workflows Perhaps, an even more controversial question to ask would be, who is responsible for applying security fixes and who is tasked with finding them?

As DevSecOps processes are being increasingly embraced, some wonder whether security hinders fast development iterations? Unlike DevOps, which is celebrated for speeding up software delivery for agile teams, security is perceived as that which slows it down. Teams need to handle top-to-bottom pressure from business stakeholders who communicate urgency for feature delivery and constantly prioritize it over technical debt and security issues. These issues often remain unaddressed and pose a potential risk of software development slow-down, and paramount business risk.

In fact, according to the Puppet report, 48% of respondents still feel that security is a major constraint on the ability to deliver software quickly.

Traditional security practices take place late in the SDLC, for example, moving a release to QA. Even for teams practicing agile software delivery based on short sprints, a security review isn't something that happens often, such as a quarterly review, and isn't baked into the development and automated build and test stages.

Integrated tooling is key

Software is 'eating the world' and it isn't slowing down, as we're witnessing more and more traditional technologies tunnel into the software world—from software-defined networking to cloud providers that abstract the entire management of traditional services into Infrastructure as Code (IaC).

As software continues to control more of the world around us; developers are key to effectively addressing security concerns because they have a direct impact on code and its security. We're seeing this change being embraced within leading developer ecosystems, such as key security integrations within the largest code repository hosting at GitHub.

To align with the agility demanded in a DevOps world, tooling must incorporate automation from risk detection through remediation. This empowers engineers to proactively address security concerns, leading to rapid risk reduction. Effective tooling should also be contextualized, making it easy for developers to assess and prioritize risk. The volume of _potential risk_at any given time is immense - creating noise for both development and security teams to address. Knowing where the highest risk exists is core to an efficient risk reduction practice for applications and services.

This not only empowers engineers to address security concerns, but also shortens the time window of exposed vulnerabilities, which results in reduced overall risk for the organization and its assets.

79% of organizations are midway in their DevOps journey

The Puppet State of DevOps report sheds light on the state of DevOps adoption and maturity in different organizations as well as how this impacts security adoption.

One of the findings presented in the report is that79% of organizations are positioned at the medium-level of DevOps evolution. Organizations also facechallenges in the form of scaling tooling, culture,and practices to effectively meet the promises andvalue of DevOps.

To help with DevOps adoption in the middle stages, Puppet recommends focusing on measuring business outcomes and make use of DevOps-driven metrics. This approach reflects the current status and provides insights into what's to be done next in order to achieve a more mature DevOps adoption.

Continue reading our DevSecOps Insights 2020 study: