Red Hat introduced Red Hat Enterprise Linux 9.1and Red Hat Enterprise Linux 8.7.
Everyone knows quality software drives higher productivity and provides a significant economic benefit to the enterprise. It is the main differentiator in the success and overall competitive edge of companies today, which is precisely why software must be secure. It sounds simple enough, but there's a problem: not everyone is on the same page on how to ensure that security is baked into applications from the onset, more specifically during the build. More, not everyone is sure of their own individual role in the larger security effort. And not everyone agrees on who is in charge.
For the good of software, it is time to bring this quandary into sharper focus. Organizations are scooping up application scanning tools to implement their application security program, but they often fall short of their expectations of such a program. Because each tool produces large and different data sets, development teams are often buried under mountains of findings without a clear path towards action. This ineffective process is problematic in many ways, first being that it is not organizationally scalable. Product teams have to meet objectives set by the security team, using the tools they are unfamiliar with, even if they are short-handed and ill equipped to consistently execute and deal with these outputs.
Further, AppSec ownership is fragmented, as security and product leaders are failing to collaborate on secure software delivery. Because each side is measured by different standards and goals, their incentives differ as well. And in many instance, they aren't communicating at all. This is where the work to improve application security is still waiting to be done.
The Truth Emerges
Fortunately, there is now some hard data to illuminate this issue. A recent research report conducted by the Ponemon Institute explores the misalignment between AppSec and DevOps.
According to the findings, 75% of AppSec practitioners and 49% of developers believe there is, in fact, a cultural divide between their respective teams. And this schism is getting in the way of productivity and security. Each team has different priorities and views. Developers are all about speed and innovation, while security folks are focused on making sure applications are bulletproof before hitting the market.
Both sides of the aisle admit there is a problem. In fact, 56% of developers insist AppSec teams do not understand the pressure they face to build and deploy software as fast as possible. And security folks say DevOps teams do not worry enough about the security of applications early in the development life cycle, which means code is often pushed out with known vulnerabilities. Further, the two sides disagree on whether or not application risk is even increasing, with 60% of AppSec professionals saying it most definitely is. But only 35% of developers agree with this assertion.
Worst of all, Ponemon's recent report highlights the fact that no one really agrees on who "owns" the larger bucket of application security. Thirty nine percent of developers say the security team is responsible, while 67% of AppSec practitioners say their own teams are.
Time to Work Together
Regardless of who is right, the work of securing software lies in the balance. If the Ponemon study tells us one thing, it's that we all need to start thinking more seriously about how to break down siloes, reshape mindsets and unify AppSec and DevOps. As software production continues to accelerate, the need for more secure release processes becomes increasingly critical. Organizations must find effective ways to bring security into the world of development through collaboration and a serious shift in perception — and this effort starts with people.
Before companies can even think about technology, they need to align their teams. Leaders and CISOs alike must complete the groundwork with both sides to establish a shared vision of more secure software. Once objectives and incentives are in place, organizations can think about moving forward to implement a more robust DevSecOps model. In this new world order, there are three things to remember about software:
1. Software development needs structure. Enterprise standards have to be upheld so business, security and development leaders can innovate with confidence.
2. Software development thrives on speed. To accelerate pipeline velocity and software delivery, organizations need to orchestrate the continuous discovery and remediation of vulnerabilities throughout the development life cycle.
3. Software development takes focus. Developers need to be unburdened so they can move past the friction and into the realm of successful innovation, meeting corporate standards along the way.
This shift in thinking isn't just good for teams — it translates into better workflows and business practices. Seventy seven percent of develops say this existing gap affects their ability to meet deadlines, which translates into lost opportunities and revenue. Securing applications is a now a business imperative, and for regulated industries with heavy compliance requirements, governance is critical and needs to be centralized. This is what allows different teams to work in conjunction with one another for the good of software.