Enterprise security best practices for managing vulnerabilities at scale

著者:

2020年11月9日

0 分で読めます

What is Enterprise Security?

Enterprise security at scale is—among other things— about addressing the following concerns:

You experience an increased clutter of security issues, wasting time for developers and security engineers.
Developers and security engineers don’t collaborate well due to a diminished sense of trust between them.
Prolonged exposure windows of severe vulnerabilities, due to failure to prioritize the most significant and fixable security issues.

How do you ensure effective security compliance across several teams when they experience an overwhelming number of vulnerabilities that need to be addressed?

This is what this enterprise security best practices cheatsheet is all about!

Download the cheat sheet.

Whether you are implementing an enterprise security architecture, or an enterprise cyber security solution you are going to face applications security challenges, such as ensuring that your development teams are not slowed down, gated, or blocked.

Snyk recently announced its Enterprise Security Management at Scale solutions, which highlight developer-first project management capabilities and focus on the productivity of your security and development teams. Features like project attributes, project tags, project-level policies, and pull requests fail conditions are all great examples of helping developers take action and supporting the security team to focus on what matters.

Take action to improve your enterprise security architecture:

only fail the build when a fix is available
automatically assign the security champion to review issues
create prioritized pull requests to fix vulnerabilities
license Compliance
reachable vulnerabilities

Create prioritized pull requests to fix vulnerabilities

Challenge: The backlog has many security vulnerabilities and it’s a struggle for developers to address security issues through the clutter.

Solution: Reduce the overall risk by focusing on the most significant security vulnerabilities that can be fixed.

Snyk introduced the vulnerability priority score to help mitigate the longtime problem of scoring security vulnerabilities, such as with the standardized CVSS, which create enormous challenges for developers and application security engineers to determine the true impact in accordance with the correct context of a security vulnerability. We wrote more about the challenges of scoring security vulnerabilities with CVSS which also serves as a good introduction to CVSS basics.

Snyk’s priority score takes into account data points such as exploit maturity, whether there’s a fix available, the CVSS score, and others, to conclude a priority score range between 0 to 1000 for a vulnerability. The higher the score, the higher the urgency to fix the vulnerability.

To help you clear the clutter and long tail of security vulnerabilities, we want to make sure you focus on the most significant security vulnerabilities in order to reduce the overall risk and exposure window.

How do we do that in a helpful and actionable way for developers?

Go into the Snyk integration settings and enable the capability to raise pull requests for all the highest priority fixable vulnerabilities that exist in the project. Worry not, this is not going to flood the developers with many pull requests and take up all their time! Instead, we’re going to open only one new pull request a day. These pull requests are actionable and have upstream package releases for which an upgrade path exists, and so should take minimal effort from the development team to review and merge.

Automatically assign the security champion to review issues

Challenge: Security fixes are automated and raise a pull request to the project repository, which is a great thing, but who should review them?

Solution: Standardize the security review of automated fixes and automated dependency upgrades by automatically assigning a reviewer to the pull request created. You can assign a person based on the last user who changed the manifest file, whether that was a pom.xml or a package.json, or specifically call out the security champion or other person in your team to help you review the changes introduced in the pull request.

Only fail the build when a fix is available

Challenge: You want to help developers build securely using open source, but you end up blocking them entirely, and oftentimes they can’t even take action on your findings.

A developer finds that the CI pipeline failed for a security issue that is low severity and they can’t move forward with their project.
A developer struggles to handle a security vulnerability that the CI pipeline found and failed the build because there is no actual fix for the security issue.

Solution: To help developers embrace security and handle failures without dismissing them as noise and false positives, you need to empower them with tools that are helpful and actionable to their workflows.

Snyk provides granular configuration to allow you to fail the CI build only if the vulnerabilities found are above a high severity threshold, which means when developers need to spend time addressing a security vulnerability because of a build environment failure, they do so by prioritizing the most important issues.

What do you expect developers to do when a CI pipeline fails due to a security vulnerability?You probably expect them to fix it. That’s great, but most tooling and integrations just fail the build regardless. This is where Snyk’s developer-first mindset comes in. The CI integration has a flag to allow you to only fail the build when issues found have a fix available. This way, developers can actually take action to remedy the security problems rather than spend endless time triaging vulnerabilities only to find out there’s no fix available.

To use all of this security goodness you can go to the relevant integration settings for your setup, such as GitHub, and tune these build failure conditions when snyk tests pull requests, for example:

Prioritize vulnerabilities reachable by your own code

Challenge: You have difficulties prioritizing which open source components to fix first, such as:

I have many security vulnerabilities in my open source libraries, but how do I know which library is used in production code?
Developers say “yes we’re using this open source library, but how can we tell if we’re using the class/method in which the security vulnerability exists?

Solution: Snyk understands that developers and security engineers need a way to better prioritize the work to triage hundreds of vulnerabilities and it solves it by applying static code analysis to determine if a security vulnerability in a third-party open source library you’re using is reachable from your own, (first party, code.

Snyk understands the context in which a vulnerability was found and takes measures to prioritize the work to fix it to reduce business risks and exposure windows.

Technically speaking, the reachable vulnerabilities feature is based on Snyk’s algorithm that builds upon a call graph from your application’s source code to open source dependencies in the project.

For the time being, Snyk’s support for reachable vulnerabilities analysis applies only to Java, Maven and Gradle projects, and it is only provided with the CLI tests or the Snyk UI when you test a project. Git support is coming soon though!

Identify security vulnerabilities based on their reachability from your code:

Make sure you’re using the latest Snyk CLI version
Navigate to the folder of your application and relevant manifest files
Run snyk test --reachable

If any reachable vulnerabilities are found, the test output will be similar to the following screenshot:

Actually, you can monitor all of this information in the Snyk UI.

Proceed to push a snapshot of this manifest to Snyk so we can monitor it continuously for you and send alerts. To monitor the project run:

snyk monitor --reachable

Now we can filter all security issues by reachable vulnerabilities and prioritize those for a fix first:

If you are interested in more information on the reachable vulnerabilities feature see the following blog posts:

A technical deep dive: Reachable vulnerabilities: how to effectively prioritize open source security by Krysztof Huszcza
The importance of prioritization of security vulnerabilities in composition analysis software: Optimizing prioritization with deep application-level context by Daniel Berman and Michael Komraz and Daniel’s write-up on the announcement of developer-first prioritization capabilities.

License compliance policies

Challenge: You’re experiencing the challenges of enterprise security software if you struggle with the following asks from the legal department:

We need a list of all your open source libraries, across all application projects.
It is imperative that we do not violate license and copyright laws by unknowingly distributing copyleft software that violates its license policy.

Solution: Snyk enables you to address enterprise security and licensing compliance issues in two ways:

It provides you with a report of all of your license usage across projects, which you can export as CSV.
It allows you to set open source software license policies, enforceable at a project and organization level, in order to stay compliant with your business’s legal department guidelines.

Software license management

Snyk’s Reports tab allows you to view all of the licenses that your projects are using, across all imported projects and organizations if needed.

You can further filter the list as needed or sort it by the number of dependencies or projects which are impacted by specific licenses. This is going to be handy to quickly prioritize the legal requirements that need to be addressed by specific license violations.

If you need to export the list for further collaboration, with another team via spreadsheet, just go ahead and click the Export as CSV button to create a software bill of materials that includes your licenses.

License policies

Establishing a license policy across an organization is a common thing to ensure the business doesn’t risk legal actions due to improper use of software libraries, or even more severe, completely violates them.

To address this concern, Snyk has the ability to set a license policy for projects to ensure that these projects fail the license check in a build, or a continuous integration pipeline.

You can set such security policies at a very granular level, to be applied to projects which match specific attributes. This helps to make sure teams have enough freedom to run independently with the proper guard-rails in place.

How do you establish a policy on the Snyk UI?

We set up policies at the group level, so you need to be a group administrator, policies apply to all organizations and projects that belong to specific groups.

As you can see, Snyk already applies a default license compliance policy for you that is tuned towards enterprise licensing expectations. You can further tweak it to match your own legal requirements.

Categorize projects effectively

Challenge: This is how you know you have an acute need for enterprise security solutions:

Developers and security engineers spend significant time finding projects they need to address.
Drowning in an ocean of security vulnerabilities and you don’t know where to start.

Solution: Setup projects with business impact attributes and tech stack metadata. This ensures that the service has appropriate criticality attention, details about the deployment environment, application characteristics, and that frontend or backend affiliation are represented well.

Bonus points: With Snyk, enterprise security solutions are taking into account feedback from our customers. We actually listen, and that’s why we know what to build. So here’s another thing that helps you understand organization ownership for an application: there’s a dedicated _Project owner_field which you can set to any user or developer who has access to the Snyk project.

If you're more into watching a video that covers this then here is a short video re-cap about managing your projects based on attributes and project tags:

The following list of projects might be intimidating to look at, right?

Which project should I start with?? How can I filter this list of projects across my entire organization or business unit?

If you’re doing SecOps, or Security Operations, these challenges are quite common. As a stakeholder for security in the organization such as a security champion, or a group leader, you probably want some help to properly address enterprise security concerns.

Here is how we solve that problem with Snyk - a picture is worth a thousand words so I’ve got one for you and you can see the list of filters on the left that help you filter your projects based on:

Issues and addressable fixes - this is a very powerful filter. You can make sure your developers focus first on the security vulnerabilities that are actually fixable and don’t waste time triaging and validating those which aren’t. Enterprise security solutions made easy!
Integrations - browse projects based on their source. Is it a project monitored via the Snyk CLI you’re looking for? Trying to search for all projects from the GitLab or Bitbucket Cloud integration?
Environment - what kind of project is this? Frontend? Backend? Maybe it’s a mobile application that you’re monitoring with Snyk’s brand new Gradle plugin support? Filter quickly here.
Lifecycle - enterprise security architecture often needs to apply security policies with regards to the application’s public facing nature. For example, if an application is entirely accessed internally by employees of a business it might be of lower criticality. This lifecycle attribute allows you to set and filter projects based on whether they are deployed to production, staging or otherwise.