Publication Release: DevSecOps Trend Report

For years, security has been an afterthought — functionality that developers and product managers often address at the last minute, right before a build is about to ship. For some individuals and teams, this practice stems from a reactive approach to security, in which vulnerabilities are expected to be dealt with only once they’re discovered after a release. For others, this stems from prioritizing additional features and functionality (and immediate ROI) over security (and minimizing risk). For most, however, the cause of this issue is more systematic in nature.

Businesses today expect speed from development teams. Too often, the questions that leaders and managers ask concern the time of the next deployment or how soon a bug can be fixed, rather than how well a problem is addressed. This mindset is innately oppositional to ensuring the security of an application. Security, like any other part of software development, is iterative; it takes rounds of testing and attention to detail from all stakeholders involved in order to eliminate vulnerabilities.

Increasingly, more organizations are beginning to realize this, and as a result, they have started to incorporate security into their DevOps pipelines. With this in mind, we sought the opinion of industry professionals and leaders about the state of DevSecOps adoption and implementation to help readers understand more effective ways to manage security throughout the SDLC.

In “Successful DevSecOps Teams Proactively Automate Responsibility,” Chase Doelling refutes the common misconception that security and DevOps cannot coexist. The same attention that’s given to software development in DevOps simply needs to be shown to security as well. Chase states, “continuous delivery means that you need to start secure and stay secure.” Just as unit and integration testing are expected to be performed throughout the SDLC, so should vulnerability testing.

Percentage of times release dates override security concerns

Chase then attacks the root of this issue, as he brings up ownership as one of the key reasons that security is often not a priority in development. According to Chase, “lack of ownership is what leads to security being treated separately, and worse, as an afterthought. The moment you feel like it’s not your responsibility, you don’t own the outcome fully and will defer when questioned.”

Michael Hollander furthers this discussion in “Open Source Security as a Use Case for DevSecOps Adoption,” pointing out how well developers test and ensure the security of open source tools they use in their applications. He then uses this model as a road map to show developers how easily best practices for open source vulnerability testing can be employed in a DevOps pipeline. In “Shifting Everywhere: DevSecOps Gets Real Fast,” Jeff Williams expands on Hollander’s road map and provides a step-by-step process that focuses on automation and continuous monitoring to implement DevSecOps within an organization. In the following section, we bolster these claims with an analysis of a survey of 391 software developers, engineers, and architects concerning the state of security in their organizations’ DevOps pipelines.

Download the full report today to learn how to shift DevSecOps left, discover open source security as a use case for DevSecOps adoption, and see how and why successful DevSecOps teams proactively automate responsibility.

This UrIoTNews article is syndicated fromDzone

About Post Author