 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Just as the move to DevOps required a cultural shift, incorporating security into a DevSecOps initiative typically requires a delicate dance between developer and security teams. The two groups historically haven’t seen eye to eye and view one another with distrust.
The tension over integrating application security and bug fixes into developer workflow is often referred to as “the DevSec disconnect.” From the developer point of view, security slows down their ability to deliver apps at a fast pace. On the flip side, security professionals perceive code as inherently insecure and not ready for prime time unless security is baked in.
The results of this disconnect can be damning. Nearly half of developers (48%) regularly push vulnerable code into production, according to ESG’s 2020 Modern Application Development Security report. Further, vulnerabilities discovered too late in the development cycle often don’t get mitigated, the report noted.
If they do, they’re more costly to fix. The longer bugs stay in the software development life cycle (SDLC), the more difficult they can be to resolve. Hence they require more time and resources.
First, it’s important to understand the mission: DevSecOps is about applying automation in security protocols and other procedures needed in the app dev process. The growing mandate for safer and quicker app delivery, coupled with a surge in cybercrimes, are major catalysts for the growth of the market.
The two teams need to come together, but there are some issues that continue to stand in the way. Here are three reasons developers struggle with AppSec.
Like in any good relationship, there have to be open lines of dialogue. Yet, both teams still get bogged down by misperceptions of what the other does, and should do. For example, Gitlab’s 2021 survey on the global DevSecOps landscape highlights that most security professionals don’t believe developers can write secure code, while most developers feel they lack proper guidance.
Adding further fuel to the fire, there also doesn’t appear to be consensus on where the responsibility lies for producing secure code. Thirty-nine percent of security respondents to GitLab’s survey said they were on the hook for security (up from 28% last year), but almost as many (29%) felt that everyone was responsible. Others (21%) put the onus on developers.
The finger-pointing game continues, and there needs to be clarity over who “owns” security in app development.
While most organizations provide developers with some level of security training, more than half only do so annually or less often, the ESG study found. Even though development managers are often responsible for this training, in many organizations, application security analysts carry the burden of performing remedial training for development teams or individual developers who have a track record of introducing too many security issues.
Often developers want to learn the foundational pieces of security, if only someone would take the time to teach them.
Many organizations tend to use so many tools that it becomes a challenge to integrate and manage them. This reduces their effectiveness and requires resources to manage the tools; resources that could be better directed elsewhere.
While application security has matured, there is no one testing technique that development teams can use to mitigate all security risks. This is why teams have to use multiple tools, often from multiple vendors, to secure the SDLC.
Usage varies, as do the tools that organizations deem most important. Most organizations end up using a “cocktail” of tools to satisfy their security needs, the ESG report notes.
Instead of adding security to their list of responsibilities, organizations should provide developers with developer-native tools to help bring security into the workflow. Rather than expecting developers to learn the ins and outs of being a security professional, these tools can guide them to make decisions with security in mind, the ESG report suggests.
Encourage developers and security professionals to collaborate and provide KPIs for them to work on and measure together. Also consider establishing a formal app security program where collaboration becomes more natural to day-to-day work.
Adopt a shift-left security approach and move security into the development process sooner through automated security testing, so developers can fix security issues fast. This can help alleviate tedious security red tape reviews. But bear in mind that some manual testing will still need to be done, since automated scans are not a complete panacea.
Finally — and this goes back to the communication component — explain to developers the value proposition and ROI of shifting left and integrating security in the earliest stages of development. Otherwise, expect the DevSec disconnect to live on.
