2020 Q2 in review—State of Open Source Security report, DevSecOps Hub, and more

Yesterday, we looked back at some of the blog posts we published back in January, February, and March of 2020. You remember, that time we were able to travel and hug each other, meet up carefree in bars and offices, and be social without having to use Zoom! Well, in this post, we look at the posts we published in April, May, and June. We’ll start with a cheatsheet that every developer should read and refer to.

SEE ALSO: 2020 Q1 in review — JVM ecosystem report, DevSecOps insights, and more

April 2020: Secure code review: 8 security code review best practices

In this cheatsheet, Brian Vermeer and Trisha Gee cover 8 great tips that we should think about when reviewing someone else’s code. In fact, these are also great tips one should be thinking about when writing code as well, so make sure you also judge yourself to these standards when coding before you even send that pull request!

Three of the best practices in the cheat sheet that I want to call out, in particular, are sanitizing inputs, testing your open source dependencies, and of course, testing your own source code for known security issues. Sanitizing input is such an important thing to do in your own code, and it’s something that we as developers often leave to others, or assume no malicious intent, as we’re just trying to get the golden pathworking. Using the mindset that users will try to inject, or maliciously attack our application with any means possible through their input is an important change a lot of developers need to go through.

Statically testing your own application as well as your third-party dependencies is extremely important to understand where known vulnerabilities in existing libraries and frameworks are being exposed through our application, as well as where our custom code is adding security flaws. With tools like Snyk freely available that tests your application quickly, and in your IDE environment, repositories, and many other places, there really is no excuse not to do this anymore.

May 2020: Snyk launches DevSecOps Hub

In May, Alyssa Miller launched the DevSecOps Hub, a collection of articles and knowledge collated by Alyssa, Patrick Debois, and Francois Raynaud around some of the core concepts of the DevSecOps movement. It presents these concepts using a familiar People, Process, and Technology approach in order to avoid the tool-centric focus that sometimes takes over the DevSecOps discussion.

People -While many of the experts at Snyk could share their own opinion, we wanted to make sure we included lots of lessons from across the DevSecOps community as well. Participants on The Secure Developer Podcast share stories with our founder, Guy Podjarny, about their successes and lessons learned in launching or growing their DevSecOps approach. To bring this valuable information to you through the DevSecOps Hub, we have included our Share the journey section.

Process - It’s always important to clearly define the process so that everybody knows what to do, when to do it, and who should do it. Establishing shared responsibility and accountability are key themes that are discussed throughout this section.

Technology - In this section, we focus on key capabilities that should be a part of any pipeline and how organizations can adapt standard approaches to better fit their own unique structure. As part of this focus, the Hub presents technology spotlights. Each of these takes a look at a specific tool or technology that can help support the DevSecOps pipeline. We also offer a list of best practices for those tools in order to provide tactical guidance for implementing those technologies.

June 2020: The State of Open Source Security 2020

In June, Alyssa Miller wrote our annual State of Open Source Security report which, as ever, found a number of really interesting insights into the adoption and usage of open source today. The first stat that the report dives into is who is responsible for security, and 85% of users feel that developers are responsible for open source security, which really backs the way Snyk thinks about security tooling needing a developer-first approach. This is a really important stat as we move into 2021, with more and more developers not just writing application code, but also needing to maintain and support container files and infrastructure configurations as code. All of these artifacts need to be not just written and maintained, but done in a secure fashion so that you’re not the next person in the news with an insecure Amazon S3 bucket being breached. In fact, later in the report, it is shown that over 30% of survey participants do not review Kubernetes manifests for insecure configurations. Developers taking the responsibility for their modern cloud native applications, need to consider the threats that exist in each of the aforementioned places and require a cloud native application security platform to support their needs.

Interestingly only 15% of our survey respondents implement Security champions programs. These programs essentially skill up individuals in the engineering teams, dubbed security champions. They are usually educated through the security team as well as other internal and external training programs. Leveling up developers really pulls a lot of the security knowledge left and can improve many development best practices, code reviews, and also helps to make security a bigger part of the design stage much more organically. People and culture are always the hardest things to change in any transformational shift such as DevOps, or DevSecOps, so it’s important to address the problem head-on. Having spoken to many Snyk customers and users, we’ve always seen organizations that create security programs in engineering teams to show great success in the adoption and execution of security practices, so please do consider it!

Once again, there were a few other posts that didn’t quite make the list but still deserve an honorable mention. These include the Vuln Cost plugin that offers a really great and free security testing tool that sits directly in vs code and provides a really great developer experience by showing where we pull in vulnerabilities inline with our code! Additionally, we covered a vulnerability disclosure that happened in the popular is-promise npm library with a post mortemof why it happened and what we can learn from it. Finally, May was the month that we integrated Snyk into the popular WebPageTest! This integration adds security testing into the great performance results which WebPageTest already provides.

Thanks for reading! Next time we’ll take a look at the posts we released in the third quarter of 2020.