Snyk is a developer-first, cloud native security platform that scans for vulnerabilities across code, dependencies, containers, and infrastructure as code. Snyk does a great job of surfacing vulnerabilities in your codebase, but it can often be challenging to map these issues back to actual services and their owners. Fortunately, Snyk’s robust API can be used to tune Snyk to integrate into solutions designed to help engineering teams understand and improve their service-oriented architecture.
Cortex automatically catalogs internal services with their dependencies and further integrates with third-party tooling (like Snyk) to provide a single pane of glass into your architecture. Using Cortex with Snyk allows businesses to not only have a full view into their microservice architecture, it also allows them to know what security vulnerabilities exist throughout.
Cortex enhances the Snyk platform by:
- Automatically mapping vulnerabilities to existing microservices
- Aggregating Snyk vulnerabilities into the service timeline, so they can be seen in context of other important service metrics, like on-call incidents
- Measuring and improving service quality based on Snyk’s data alongside other integrations using Scorecards
Mapping vulnerabilities to a service
How does it work?
After setting up Snyk in Cortex, we’ll hit Snyk’s reporting API to fetch the latest issues for the service. We’ll then display these issues in the Snyk tab of the service where you can also view other service information. You can apply additional filters to quickly find what you’re looking for.
Why is this important?
Engineers can quickly view Snyk issues that a service has and can prioritize fixing the critical ones.
Snyk in the Service Timeline
In addition to seeing the Snyk issues for each service, you can also see them next to other service events, such as Kubernetes changes, Git commits, deploys, and on-call incidents — all on one service timeline. This is particularly powerful during an incident when you need to quickly find the root cause of the problem.
Now that you have the Snyk data for each service, you can create Scorecards. Scorecards let you define best practices across a set of services and grade your services against whether they are meeting those rules. With the Snyk integration, you’ll be able to check:
- If a service has any Snyk projects set (will try to autodetect based on repo name)
- The # of all (non-ignored, non-patched) issues
- The # of all issues, optionally filtered by severity and fixable/non-fixable
You can combine these rules alongside others to measure operational readiness for a service. A Scorecard that does this can help you know when a service is ready to be deployed to production. You can check that there are runbooks, dashboards, logs, on call escalation policies, accountable owners, and no vulnerabilities:
- owners.count > 2 – There are owners defined for the service, so in case of incident the accountable team is clear.
- oncall escalations count > 1 – There are at least two levels in the escalation policy, so that if the first on-call does not ack, there is a backup.
- runbooks count >= 1 – There are runbooks in place for the service. This creates a culture of preparation.
- number of links (type = logs) > 1 – When there is an incident, responders can easily find the right logs (usually load balancer logs and application logs).
- dashboards count >= 1 – There is a standard Grafana dashboard defined for the service.
- Compare custom data to boolean: "pre-prod-enabled" = true – Use an asynchronous process to check whether there is a live pre-prod environment for the service, and send a true/false flag to Cortex using the custom metadata API.
- Snyk issues with HIGH severity = 0 – Ensure that production services are not deployed with any security vulnerabilities.
Once you have a Scorecard like this set up, you’ll see a stack ranked list of services graded against these rules.
It’s simple to get started — just add your organization ID / API key in your settings page. After you do so, we’ll map services to the Snyk project associated with the repo directly in the service catalog.
Afterwards, you can go to your Scorecards and add a couple of the rules above. You’ll now start grading the quality of your services using vulnerabilities found in your codebase! If you have any questions or need help setting up this integration, please email firstname.lastname@example.org.