Everything is speeding up. In the summer of 2001 the Code Red, Sadmind, and Nimda computer worms wrought havoc on computer systems and IT teams around the world. As a result, 2002 heralded the infamous Bill Gates memo. It redirected whole divisions of the Microsoft juggernaut towards a new Secure Development Life Cycle (SDLC) methodology for designing, building, and shipping code. The entire Windows developer division effectively dropped tools and was diverted to focusing on security.
Today, there are still organizations that consider security an afterthought, but for others, security has become a competitive advantage that actually accelerates them, rather than being perceived as a blocker. Security, when embedded as part of a frictionless development cycle, can actually be a selling point, one that can save time and money, while reducing risk. Unfortunately, security teams are often overstretched and don’t have the required visibility or tools to help with the software development lifecycle. They rely on security testing after the fact, when software has already been released to the wild, rather than testing before it is shipped. This late testing rarely fixes or corrects the underlying systemic issues and instead provides a window of exposure for exploitation. But by combining platforms like Snyk and Tines as part of your Security Process Optimization (SPO), teams can automate and collaborate non-intrusively, allowing engineering teams to ship secure code faster.
Security has never been so crucial as with SaaS (Software as a Service) which is a constantly moving target that’s never entirely ‘done’. Feature velocity tied with device and browser support challenges leads to code churn, which can lead to more bugs and vulnerabilities. With modern CI/CD (Continuous Improvement / Continuous Delivery) pipelines, shipping to production can happen many times a day, and with a global service footprint, complexity and security considerations are elevated. This acceleration brings with it risk, and testing becomes even more critical. It’s not just your homegrown code that may suffer vulnerabilities, but external dependencies and packages can also undermine you or your customers' security posture.
Continuous improvement should imply 'continuous security', but is this really achievable?
So from a security operations perspective, the question then becomes, how do we automatically track, record, and address risk in near-real or Internet time?
Snyk empowers developer-first security with automated vulnerability detection and remediation (including even highlighting licensing issues). Their leading vulnerability database enables comprehensive open source coverage and goes beyond CVE vulnerabilities and other public databases. Snyk also delivers tight integrations with all leading code management, container, and CI/CD platforms which accelerate software and service delivery. For teams, security adoption relies heavily on being frictionless, and this is what Snyk focuses on. But we can go even further with Snyk and Tines to automate closed-loop workflows, not just for AppSec (Application Security) teams, but also SecOps (Security Operations) and DevSecOps (Developer SecOps).
For our practical example, we will fork a modern web application ‘scaffolding’ project on Github called ‘limestone-accounts’. It contains a basic Gemfile manifest for Rails that, once we intentionally revise down some gems, Snyk can get its teeth deep into! Just to note, we’ve also removed the package.json manifest to simplify the Story and focus on RubyGems for now. Once we’ve connected Snyk to our designated Github branch, Snyk can automatically test our Gemfile.lock for vulnerable gem versions. This happens when a Pull Request (PR) is opened or updated. Snyk even offers its own PR (Pull Request) with a patched manifest file to remediate vulnerabilities if relevant packages are available.
( Current security exposure on our demo web application )
As you can see, we’ve got some “High” (4) and “Medium” (10) vulnerabilities in our project. Two of them having arbitrary code execution, and one of them already has proof of concept exploit code (shown below).
( High severity vulnerability with arbitrary code injection and proof of concept code )
Keeping track of our current and historical exposure for visibility and fine-grained reporting is where we’re going to call in Tines to do some heavy lifting! Snyk already has basic integration with Jira as a system of record, but we’re going to use Tines to automate the opening, closing, and validation of fixes with our issues. This will ensure full coverage and an automated process for any security or engineering team.
Tines already supports Snyk out of the box using multiple templates, so all that’s required are your Snyk API keys, and you can start using Tines templates as building blocks to create your own Story workflows (or use ours!). As you can see below we have two entry points into our “continuous security” Story.
We will check Snyk on a schedule and ensure we have Jira cases automatically opened for any vulnerabilities found in our project (this includes automatically closing issues that have been patched, resolved, or intentionally ignored due to non-applicability, etc.).
If anyone tries to close a Jira vulnerability issue, but the vulnerability is still present, we will automatically reopen the Jira issue. This is achieved via webhooks on issue transitions that we filter for, match, and take action on.
( Tines “continuous security” Story for Snyk and Jira )
Tines has now automatically opened (14) vulnerability issues in Jira while also auto-populating the descriptions and even custom fields with pertinent security information.
( Auto-issue generation of Request Type “vulnerability” )
We have automatically set the priorities and fields according to the vulnerability data. This enables sorting by things like CVSS Score, priority, or building custom dashboards.
( Issue details for one of our most pressing vulnerabilities )
Let’s now merge Snyk’s suggested branch to fix these issues. Snyk’s check bot has generated a PR (below) to remediate the vulnerabilities.
( Snyk fix from snyk-bot )
Which then results in a project free from known vulnerabilities!
( Snyk project view with no known vulnerabilities )( Snyk project view with no known open source vulnerabilities )
But what about our security team and the 14 open Jira issues? This is where our Story workflow becomes modular and uses a powerful Tines Action called “Send To Story”. It allows us to separate out and independently evolve our automation stories.
( Send To Story modularity for initiating“Close Fixed Vuln Issues in Jira” )
Each time our main automation runs we also initiate a sub-story to do ‘mop’ up duty and validate whether we have any orphaned Jira issues that need to be transitioned to “Done”.
( “Close Fixed Vuln Issues in Jira” detailed Story workflow view )
The magic here is in the “Find Fixed Jira Issues” step which is the only one that uses a little bit of liquid templating. This allows us to compare two arrays in one step, with each array consisting of;
issues in Jira that have Snyk vulnerability attributes, and
outstanding issues in Snyk (i.e., open vulnerabilities)
The ability to use Shopify’s liquid scripting in Tines Actions opens up new possibilities to create increasingly intelligent steps behind the scenes. We output any Jira issues that list stale Snyk Vulnerability IDs and then promptly transition them to “Done”. The below liquid is just to give you a flavor of the extra power that Tines can bring to bear behind the visual Storyboarding when required.
{% capture jira_issues_to_mark_done %}
{% assign snyk_active_ids = get_snyk_issues.body.issues | map:'id' %}
{% for element in search_snyk_issues_by_project_in_jira.body.issues %}
{% unless snyk_active_ids contains element.fields.customfield_10039 %}
{{ element.key | strip }}{% if forloop.last != true %},{% endif %}
{% endunless %}
{% endfor %}
{% endcapture %}
{% if jira_issues_to_mark_done.size > 3 %}
{{jira_issues_to_mark_done | split: ',' | as_object }}
{% else %}
{{ "[]" | as_object }}
{% endif %}There are many powerful uses and templated integrations with Tines, but with just the basic building blocks, you can connect to and automate any endpoint providing a RESTful API. Many security teams are overwhelmed, but by embracing flexible and robust forms of automation, they can regain the upper hand and breathe a sigh of relief.
This is just one use case but the opportunities to extend this automation are endless. We've shown you how to automatically open and close Jira tickets for tracking purposes, however, you can easily go a little deeper and automate many other use cases including but not limited to:
align vulnerability ignore policies further between Snyk and Jira (and/or generate issues and cases in ServiceNow / TheHive etc.)
alert SecOps via PagerDuty if a certain CVSSv3 vulnerability criteria is met (and remains in production for a certain length of time)
create custom dashboards with metrics per build, team, or project
validate the presence of remotely exploitable code by initiating automated scans
create custom notifications across multiple Slack teams and workplaces
leverage Tines prompts to human-gate keep additional steps or new modular Story workflows
just to name a few...!
Whether you’re in AppSec, SecOps, or DevSecOps/SecDevOps, there’s nothing like peace and time to ponder the mysteries of the Universe (before the next storm looms on the horizon)!
Download and import this Story from our Story Library to track Snyk issues in Jira.
Loading story...