Feb. 14 is Valentine’s Day, a day to express affection and celebrate the significant relationships in our lives. For some, it’s a great excuse to enjoy a gourmet meal with a loved one, or maybe even just a glass of wine on the couch. For others, it is a day to make their relationship permanent — according to Bing, 50 percent of marriage proposals happen on Valentine’s Day.
Like any relationship, DevSecOps works best when there is a solid commitment. How can you do something special this year to move the needle and take your relationship with DevSecOps to the next level?
Commit to Application Security Testing
If you really want DevSecOps to work, application security needs to be more than an item on a checklist on the way to production. If we aren’t careful, running a scan can become a lot like the old practice of running a nightly build, which would reveal that code compiled, linked and could be deployed. That is helpful, but here’s the real question: Did you do anything with that build to test, validate and verify it? And what happened when a new build was done the next night? In many shops, QA teams were left testing builds that were days or weeks old, and when defects were found, they didn’t know to which build or configuration they applied, leading to confusion and lost time. In today’s DevOps world, continuous integration is the norm, yielding much more meaningful impact on speed and quality.
In the same way, if we are running scans as part of our DevSecOps pipeline, we are bound to identify vulnerabilities. But what next? Is application security a gatekeeper or simply a to-do? If a vulnerability is found, how is it examined to determine its severity? If it is found to be severe, does that stop the pipeline? Is there a process in place for feedback about security vulnerabilities to get to development teams quickly and in context? To improve your relationship with DevSecOps, you need to fully understand and embrace the notion that application vulnerabilities are critical to the overall quality and success of what ends up in production.
Communicate the Real Issues
We’ve all been in situations where we either misunderstood what someone else was saying or felt we were not being understood — sometimes both at the same time. Or maybe we didn’t have all the information we needed to make the best decision. We can relate to the famous line from 1967’s “Cool Hand Luke”: “What we’ve got here is failure to communicate.”
Great communication in the DevSecOps world elevates security from obscurity to an essential component of consumer trust. It is also the difference between a culture that values security and one that merely tolerates it. With that in mind, let’s explore some critical communication skills that can take your relationship with DevSecOps to the next level.
First, communicate the real issues. We all know that security scans, particularly static application security testing (SAST), can be noisy. Do your teams spend a lot of time chasing false positives? If so, that is just eroding trust and increasing the likelihood of missing something important. It’s time to build trust by leveraging artificial intelligence (AI) and machine learning to help filter those out.
Second, talk about the elephant in the room. According to a Stack Overflow survey, more than half of all developers are contributing to open-source projects, and a GitHub survey found that 98 percent of developers are using open-source tools. Clearly, open source is everywhere, and it provides a lot of power to add software development efforts. But, as Uncle Ben famously said to his nephew Peter Parker in Spider-Man, “With great power comes great responsibility.” Do you have a reliable software inventory? Does it include open-source tools and usage? Does everyone agree on it, and is it well maintained? If you are working with third-party vendors or outsourcing development, are you validating the code you receive, including open-source code? When it comes to open source, we have to ask the hard questions and be willing to have difficult conversations. Rest assured, it’s worth it in the long term.
Third, get to the root issues and deal with them faster. As much as we would love to think all our released code is perfect and secure, we know that isn’t the case. New vulnerabilities are found and exploited every day, and that application we knew to be secure last week could be suddenly vulnerable today. Finding and fixing your false negatives before the bad guys do is critical to maintaining trust. Is your tooling able to help you identify potential blind spots? For instance, can it alert you to the use of a new framework against which there are no tests? If a new exploit is announced, can you quickly and reliably cross-reference it against your software to see your risk?
Build a Winning Security Culture to Overcome DevSecOps Challenges
If you have been in the DevSecOps space for any reasonable amount of time, you know it can be challenging. Constant market pressure to deliver features and capabilities at speed, coupled with a market that is full of similar options, means that competition is everywhere. In this environment, trust is becoming a form of currency, with security and privacy being the key elements — and customers are prioritizing security more than ever before.
But each time you include and document security requirements in an application during design instead of after coding, you build credibility into your DevSecOps. Each time you identify a significant vulnerability and deal with it before production, you further develop that trust. And each time your efforts to shift left result in more developers embracing security testing as an integral part of their code, you establish DevSecOps stability. All of these elements are crucial to building a winning cybersecurity culture.
We all have relationship goals. With a firm commitment, better communication and perseverance in the face of challenges, you will be well on your way to making DevSecOps your Valentine in 2019.
The post Take Your Relationship With DevSecOps to the Next Level appeared first on Security Intelligence.
