Lessons from Snyk: Make smarter decisions about your application’s security

Snyk built a successful GitHub Marketplace app that adds additional vulnerability testing for open source dependencies. They also released their 2019 Open Source Security Report. Liran Tal, Developer Advocate at Snyk, shared a few key takeaways from their report and advice on integrating security into the development process.

Developers drive impact through innovation. Socializing and collaborating on each other’s source code is essential to how developers learn, communicate, and reinvent themselves. Recently, full-stack developers have taken more ownership of the delivery and concerns of their applications, beyond their core responsibilities. Some would consider full-stack developers as going beyond the backend and frontend application stack and extending into ownership for continuous integration and delivery automation.

This is largely made possible due to abstractions that emerge and allow developers to take part in activities beyond pure development without having in-depth knowledge. One example: deploying serverless or Docker-based applications. Developers can own the manifest files, such as a Dockerfile, to share the requirements for their applications and then allow the infrastructure and the organization’s DevOps experts to further own the scalability, elasticity, deployment, and recovery models of these applications.

This cultural shift is easier to transition to, thanks to the variety of GitHub Apps that can be easily integrated with projects. GitHub Apps allow developers to benefit from capabilities that build on top of GitHub’s—and they don’t need to be an expert to build them.

Taking ownership of security

As part of the 2019 Open Source Security Report, we found that developers increasingly feel that they should be responsible for owning additional parts of their application stack—including security.

According to the survey, 81 percent of respondents believe developers should own the responsibility for their applications’ security. Being aware of security concerns is a positive behavior that complements a developer’s sense of ownership for what they build. This also aligns with the report’s data that shows an 88 percent increase in application library vulnerabilities over the last two years. Developer awareness and involvement throughout their project’s software development life cycle (SDLC) shouldn’t go unnoticed—how can we empower developers to be more responsible and take action on their application security?

Should you integrate security early in the development process?

Security is a broad field, and even within application security, there are many topics to cover. By addressing application security concerns early on in the SDLC process, developers are creating a security-aware mindset.

Developers who are empowered to own the security of their applications and code can benefit from considering security from the start. This begins with secure coding conventions, security code reviews, adhering to security practices such as least privilege, and quick wins for integrating security tooling in their development workflows.

With that said, the previous survey showed that 37 percent of users don’t implement automated security testing in their continuous integration pipelines. And only 14 percent of users test for known vulnerabilities in their Docker images. We can’t help but wonder if developers are so motivated and encouraged to own the responsibility of their application security, why are over half of them not in the habit of practicing security testing?

Developers will gladly embrace tools that focus on the area they’re most comfortable with and those embedded in their very core development workflows: their IDE, source code repositories, and project build tooling.

The effects of integrating security too late or not at all in the development process can be expensive and hazardous. Security bugs are costlier when they’re discovered in later phases—during testing or maintenance. Snyk builds on GitHub’s existing security capabilities with an additional layer of actionable advice and remediation that is built into your daily activity. This approach makes a world of change: for example, consider a pull request that is automatically opened against a developer’s project that remediates a security concern. This can be reviewed and merged to upgrade the affected library in the same workflow everyone is already using.

As software delivery speeds up and teams aim to deliver value as soon as they can, addressing security concerns as early as possible is necessary, just like testing. By incorporating actionable security advice with significant and valuable integration to existing developer workflows, security testing can now keep up with the fast pace of modern software development.

Taking action

You already benefit from GitHub’s security features, and Snyk on GitHub Marketplace adds value with additional security testing for vulnerabilities in your open source dependencies. If a pull request attempts to add a library that includes a known vulnerability, either directly or through other dependencies, the pull request tests will fail and the developer can take action.

If a vulnerability was disclosed after an application has been deployed, a security tool can proactively open a pull request with changes to your project’s dependency management, and any lockfile associated with it to provide actionable remediation. A developer can then review the dependency upgrade proposal, confirm that all tests pass, and merge changes to lower the security risk.

Get Snyk from GitHub Marketplace