How OpsLevel can help you improve your security posture

As a member of the SecOps team, you have access to the list of security vulnerabilities that were identified by tools that scan your codebase and container images. These vulnerabilities may have been on your list for some number of sprints and you may be wondering how you are going to get them included in the development backlog, and how you can ensure remediation. 

It can also be a struggle to assess the overall security state of your architecture. With thousands of scans and hundreds of services, how can you easily identify which services and teams are out of compliance and falling behind?

We encourage our customers to leverage the OpsLevel Service Maturity Rubric to set and enforce tolerable levels of security risk.

Setting up security-focused checks

Opslevel Service Maturity rubrics are composed of checks, the individual tests that can inspect and evaluate the results from a security scan for each individual service. OpsLevel will evaluate which services have a certain level of critical vulnerabilities and the service will fail those checks. Once the vulnerability is remediated then subsequent scan will produce a passing result. It’s a visible indicator of improvement in your security risk. 

Rolling out security upgrades with campaigns

OpsLevel campaigns let us drive to completion important engineering initiatives like major upgrades of software versions. We use the endoflife API to monitor the end of support for different languages and tools in our tech stack. For example, we may see that the current version of our database engine is going to be unsupported in eight months and we need to upgrade. We can make an informed decision about what pre-work is needed and what sprints to schedule the upgrade in, then we can run a campaign to manage this work. 

Here is a sample bash script that retrieves information about different end-of-life dates per service.

 #! /usr/bin/env bash

function pull() {
    curl -s https://endoflife.date/api/$1.json > $1.json  
}

function aggregate() {
    jq -s '{"mysql": .[0], "ruby": .[1], "rails": .[2], "nodejs": .[3], "vue": .[4]}' mysql.json ruby.json rails.json nodejs.json vue.json > aggregate.json
}

function push() {
    SERVICE=$1 jq -s '{"service": env.SERVICE, "data": .[0]}' aggregate.json > $1.json
    curl -X POST -H "Content-Type: application/json" -d @$1.json $2
}

pull mysql
pull ruby
pull rails
pull nodejs
pull vue

aggregate

push $1 $2 

It takes two arguments: the service alias and the OpsLevel Custom Event Check integration URL (replacing end of the URL with the appropriate identifier). This script will use a webhook to send the payload to OpsLevel for evaluation. Here is an example of running this script. 

endoflife.sh my-service-alias https://app.opslevel.com/integrations/custom_event/XXXXXXXXXXXX

The Campaign check in OpsLevel will have the following success criteria. This criteria would be for tracking a mySQL version upgrade.

.data as $data | "5.7" as $version | $data["mysql"] | if . == null then [{"cycle": $version, "eol": true}] else . end | map(select(.cycle == $version)) | first | if (. | length) > 0 then (if .eol == false then true else (.eol > (now | strftime("%Y-%m-%d"))) end) else false end

Campaigns have future scheduling so the engineering teams will know when to complete the work. Campaigns will track which services have been upgraded to using the updated version of the database engine and which are falling behind schedule and tiers help us identify how critical that might be to the business. 

This combination of OpsLevel campaigns to drive upgrades and service maturity checks to track tolerable security risks works well in managing the security of our stack and that of our customers. 

Managing vulnerability in software development

Ideally, security best practices are baked in from the start, as software is being developed—and not retroactively applied. At OpsLevel, we focus on developing and maintaining a strong understanding of the tradeoffs between product development speed and security processes and procedures that we put into place.  

Managing security risk with service maturity checks gives us insight into our current security posture and allows us to take action when and where it matters most. For example, is it worth putting a blocker in the Continuous Integration (CI) pipeline of a tier 3 alpha lifecycle service? You might slow down innovation and development speed when you need to move fast because you are prototyping a completely new feature. You should be very cognizant of the implications and not just put a bunch of toil on developers to make things more secure. Is the juice worth the squeeze? 

With an understanding of these trade-offs, you can make incremental progress toward the security ideal without hampering developer effectiveness. 

‍

Ready to see how campaigns and service maturity checks can level up SecOps throughout your org? Book a demo with our team and see OpsLevel’s security features in action.