Inserting security in pull requests — in a developer friendly way
Inserting security in pull requests — a developer friendly way
ShiftLeft Inspect now offers a self service platform that enables developers to insert security (SAST) in their workflow, in a developer friendly way! This post describes a simple four part process to deploy static code analysis tools in your pipeline
A brief aside
Recently in January of 2020, we at ShiftLeft did a survey with a multitude of developers representing 43 development shops. When asked about “best time to to discover code security issues”, largely unaided, inserting security at pull request was the predominant response for ~85% of the respondents.
Mind you, this was a desired wish of the survey participants and not what actually happens today in their organisations. For when we actually interviewed folks 1:1, most were still locked in post build security process, something they absolutely wanted to get rid off.
This was a pleasant surprise — while we at ShiftLeft have advocated insertion of security at pull requests, this intensity of response surprised us. Clearly the code analysis (static) is ready for an upending of existing models.
How does the pull request based security workflow looks like?
We are proposing static analysis tools will need to live as ideal citizen of a development pull request workflow. The idea is to provide full ownership of security process to developers as laid out this four part process:
Configure static analysis and run as mandatory status check for GITs
A Git administrator can configure any tool to be run as part of pull request as mandatory status-check. ShiftLeft Inspect code analysis as a mandatory status-check can be enabled through branch protection rules.
Customize security build rules (e.g. fail the build if SQLi is found)
Once ShiftLeft Inspect been integrated into the build pipeline, ShiftLeft Inspect allows developers to configure a set of rules to determine what happens if certains types of vulnerabilities, secrets, hotspots etc. are discovered. A common action is to fail the build, however it is not mandatory and other actions could also be used.
These build rules are written into a YAML file that can be checked into the code repository. This provides complete control for developers to define and control the evolution of build rules.
Allow developers to self-define course of action (fix, ignore, fix later, mark as false positive)
In a normal course of action, as is the case of software bugs, a developer might fix the bug or ignore the issue as low priority orassign the bug to another developers or simply ignore the issue as not to be fixed.
ShiftLeft Inspect offers developers the same menu of options for its software vulnerability issues eliminating any need to learn new workflows.
Ability to self-service SAST policies by developers
Finally, as is the case with any tool, it requires customization to fit with the nuances of its deployment context. For ShiftLeft Inspect, it translates into tuning of vulnerability policies to reduce the false positives and much sharper results that takes into account specific nature of apps/organisation.
ShiftLeft Inspect provides a self service platform for any developer in an organisation (with appropriate privilleges) to tune policies for all apps, single app or even to the extent of a single scan.
Here is a video walkthrough of pull request integration process
ShiftLeft Inspect is free for upto five developers and upto 200K lines of code.
Inserting security in pull requests — in a developer friendly way was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Alok Shukla. Read the original post at: https://blog.shiftleft.io/inserting-security-in-pull-requests-in-a-developer-friendly-way-4dbc9f9997c4?source=rss----86a4f941c7da---4
