Perhaps you’ve seen the delightfully clever new ad for the iPhone and Apple Watch integration, in which a farmer taps a button on his watch that then signals his phone, lost in a huge haystack, to beep. He reaches in and finds it in seconds.
Pre-Apple Watch, we might characterize something like this as a rather Sisyphean task, that in turn consumed hours that could have been spent on his actual job. Developers may sometimes feel like they’re working in an environment akin to that. Lacking the right tools, training and organizational processes to identify potential vulnerabilities or compatibility issues in their code, they’re nonetheless expected to ship code sans those needles.
“The developer’s job has expanded a lot more into compliance. However, education hasn’t kept up, accountability hasn’t kept up and training hasn’t kept up,” Revenera’s Alex Rybak said on a recent webinar. “So developers are in an almost impossible position, where a lot is being asked of them, but they haven’t been provided adequate information, guidance, processes and frameworks to work within to be able to achieve those.”
But, as the ad shows us with the Apple technologies, with the right tools, training and processes, that age old proverb can be flipped on its head.
Organizations can create a culture that makes it easy for developers to build secure code, and how to do so was a big theme in a recent webcast, “Closing the Avoidance and Remediation Gap in Open Source Compliance.” Alex joined Matias Madou, who is CTO and co-founder of Secure Code Warrior, to share some tips on building a security mindset amongst developers in order to move from a reactive approach to fixing issues, to proactive approach that prevents them from becoming issues in the first place.
- Start left. How, from a security perspective, can we help the developers ship reliable code? Upskill developers in security from the start, and make sure they have the knowledge to fix the problems. The more educated the developer is on the importance of security at component selection time, including what to do upfront about avoiding problems, proper testing, exposures and more, the better off everything and everyone is down the line. And don’t make training a one-time event — keep up with it, and make sure it evolves with the needs of the developers and the environment they’re working in.
- And start small. Pick one thing to focus on. This could be a project that fits whatever technology you use, or a team that is struggling or is mission critical. Focus on making that team successful so that they become the champions of security culture. Organizations make the mistake of starting off too big and then failing to prove the value. Don’t focus on all languages or the entire stack. Learn from the smaller projects, and then do more.
- Make sure to bring in the software architect. The reality is that teams are distributed and may work on certain parts of the functionality. All of these parts eventually come together in the software, but the teams may never talk to one another. Architects bring the broad, organizational view, and should have a better understanding of the dependencies, understand the vulnerabilities that are important for the organization, and soft points in the code.
- Balance friction between compliance and security culture. Time was, compliance was driven by the legal function. Now security dominates. The two functions have different agendas. Security isn’t interested in preventing the risk every fragment of code exposes the organization to, but only what’s vulnerable. Legal aims to eliminate all risks. And time puts constraints on what’s possible across both of those agendas. Organizations that prioritize what’s business critical best balance these two aims.
- Prioritize certain projects. Which segues well into our next point. There is a never-ending stream of vulnerabilities, but not every vulnerability affects your code. Security and product teams need to work together to say, if this type of vulnerability arises, is it a problem for us? Look at your own projects, code and technology stack and figure out what is the most important. Understand which projects are more important than others as well as other factors — how the software is distributed, where the attack vectors are and the environmental factors of the server it’s sitting on. Look at CVSS scores and severities to start, but with the understanding that their rank or rating may not directly apply to your organization. As Matias said, if you don’t have a database, SQL injection isn’t relevant for you. Figure out what your own top 10 issues, or top 5 or top 3, are.
- And document what you won’t address. Because some scans will yield what are false positives for your organization, document vulnerabilities that come up in scans that you’re not going to address, including why you chose to deprioritize it – because your customers will want to know why or how you plan to address them.
- Educate everyone about the importance of a Software Bill of Materials. Federal requirements recently enacted to sell software to the federal government will almost certainly become expected in the private industry – even if it’s not officially regulated. If you haven’t catalogued what you’re using, you can’t respond and learn from it. Make sure there is a process to identify known security vulnerabilities, make sure you monitor it and improve it and have a policy in place and a process to patch. Keep the sBOM up to date, and ensure people are continually educated on it. Alex specifically recommended Linux Foundation VP Kate Stewart’s recent webinar.
Shifting Software Composition Analysis left (or as we like to say, expand left) helps developers do their jobs – innovate, build, and ship reliable code – and reinforces their place as a key figure in the entire ecosystem. As Matias said, developers “want to do the right thing.” Let’s give them the support to do so.
