We are very excited to announce the GA release of SourceClear Custom Policies. Custom Policies improves issue remediation and allows you to take greater control of your software delivery workflow.
Why Do You Need Custom Policies?
More than ever, development groups are relying heavily on open source software libraries to provide a rich feature set that can’t be built from scratch in a reasonable time. Those same time constraints mean that DevOps pipelines often omit security testing, while those that include it can be overwhelmed with too many issues to remediate.
Using software composition analysis tools like SourceClear turns the DevOps pipeline into DevSecOps, which solves the first problem. Now, with the release of Custom Policies, you can fine tune the remediation signal-to-noise ratio to your company’s needs, removing the second obstacle.
What Can Custom Policies Do?
SourceClear has always had a security policy under the hood that created an issue each time we identified a vulnerability in direct or transitive libraries, a direct library that is licensed under GPL, or a direct library that is out of date.
With the release of Custom Policies, we have extended those controls to Enterprise accounts. Not sure if Enterprise is right for you? That’s okay—it’s included in our trial, too, so you can try it for free for 30 days. You can decide when to create a SourceClear issue and when to break the build. Set your own severity for different kinds of control violations. For vulnerability issues, choose whether that severity is based on a CVSS score or set it manually. Best of all, each workspace can use the default policy or its own custom policy.
How Does It Work?
In your workspace, navigate to the “Policy” page, where you’ll see the default policy in effect.
Customize any of the existing rules, called “controls.” For instance, to break a build when high-risk vulnerabilities with vulnerable methods are found, set the control’s level to “Error.” This setting will return a non-zero response, which can be used by CI build scripts to break a build.
To change the priority of an issue, update the severity for the control.
Enhance your policy with controls that aren’t included in the default policy. You can now take action when libraries are found with multiple licenses or without any license.
Delete any control, and no more SourceClear issues of that type will be created. For example, if your organization is not focused on updating out-of-date libraries, delete the following control and your issue count will drop in the next scan:
If you need to start your customizations over again, just click “Reset to default policy” and start fresh.
Finally, you can toggle between using a custom policy and the default policy at any time, and your selection will be in effect at the next scan. Prior issues will not be affected. If you return to the default policy, the system will remember your custom policy for future edits.
Ignored issues now stay ignored. Previously, you could use the scan directive
fail_on to break a build on a limited number of controls. If you rescanned after ignoring an issue that caused the build to fail, the build would still fail. This release replaces
fail_on with the new policy engine. Once you ignore an issue, it will no longer cause the build to fail, which reduces false positives and interruptions.
Issues listed in the CLI output. For paid and trial accounts, the SourceClear scanner now lists the same issues in the scan output that you would see in the webapp, giving you more immediate feedback about problems detected.
More granular issue severities. To help you triage your issues more accurately, the Severity column on lists of issues displays numerical values instead of icons for low, medium, and high.
With Custom Policies, you can ensure that no software ships unless it meets your security requirements, while avoiding any superfluous information. We hope it increases your productivity and look forward to your feedback. To learn more or upgrade to Enterprise, contact [email protected].