Hot Topics
Application Security DevOps Security Bloggers Network 
SBN

Increasing your AppSec velocity with ShiftLeft

by Katie Horne on February 3, 2022
Photo by Andrea Piacquadio from Pexels

As the velocity of the software development lifecycle (SDLC) increases, so should the velocity of everything that gets integrated into the SDLC. This includes application security. To that end, ShiftLeft released the Velocity Update for ShiftLeft CORE, which we’ll discuss more in the following sections.

Increasing your AppSec velocity

The earlier that you identify security vulnerabilities in the SDLC, the cheaper it costs to fix the issue. However, the key to successful integration of application security (AppSec) into the SDLC is to ensure that AppSec can keep up with the speed of development. ShiftLeft offers the following features to help you identify vulnerabilities and get them fixed ASAP:

  • Easily digestible information regarding findings via SAST and SCA
  • Seamless integration into the development process
  • Build rules to help automate decision making
  • Interactive remediation to allow the customization of automation

Integrating ShiftLeft CORE into your workflow

The cheapest time to fix a vulnerability is during development, but to do so, the developer who is working on the code must know that they’ve introduced an issue. Furthermore, the scan must be quick — lengthy scans slow down a developer’s velocity and run the risk of being ignored as they move on to another task.

To that end, ShiftLeft integrates seamlessly into your version control workflow so that the developer gets code analysis results (typically available within minutes) before they merge their changes into the main branch.

Reviewing findings information

With automated scans that you can build right into your development pipeline (e.g., integrated into your Git-based pull request process), ShiftLeft CORE allows you to obtain information about any vulnerabilities you’re introducing into your code every time you’re ready to merge in a set of changes. For many teams, this is an increase in the frequency of security testing. To that end, we needed a way to present information to users without overwhelming them.

Over the years, we’ve worked with developers to create a dashboard that presents them with the information they need to tackle vulnerabilities. In addition to displaying all of ShiftLeft’s findings, the dashboard features:

  • Easy-to-use filtering and sorting functionality
  • Branch-based views, allowing users to see only information related to a specific branch that’s being worked on instead of the application as a whole
  • App groups, allowing users to group like projects (e.g., an app group might consist of all scans for an application where the developers have chosen to scan components individually)
  • Searches for language-specific results (e.g., find only those vulnerabilities present in a Java language app)
  • Detailed vulnerability descriptions that include an explanation of the root cause, suggested remediation/mitigation, and why the code as-is leads to a vulnerability. Developers also see information regarding best practices and language-specific code samples that will eliminate the issue

It’s a fine line between providing enough information for developers to act on vulnerabilities that are identified, even at the early stages of the software development lifecycle,

Increase the velocity of fixes with Build Rules

Automation is king for busy developers, and ShiftLeft CORE again strives to balance between presenting developers with information that’s helpful for decision-making and allowing automation to make similar determinations.

One way that ShiftLeft helps with this is via build rules, where developers can determine the rules and the parameters against which their code is measured. For example, developers can write rules using vulnerability types and categories, severity level, and OWASP type as parameters. With build rules v2 (part of the vulnerability update, ShiftLeft CORE has also introduced the ability to flag OSS vulnerabilities as well.

If their code meets the defined standards, ShiftLeft will flag the code as good-to-go; if not, ShiftLeft will indicate that the build should fail.

The fine control teams have over the type of findings that trigger build rules is critical — not all vulnerabilities are of equal severity; not all vulnerabilities should be treated with equal importance.

Leveling up with Interactive Remediation

Build rules are excellent for influencing the development pipeline based on analysis from ShiftLeft CORE (e.g., fail the build if there are five or more vulnerabilities of the specified type). However, with interactive remediation, developers can define rules and patterns ShiftLeft CORE uses to determine if a potentially problematic area of code should be included in scan results or not.

Furthermore, suppose developers implement custom validation or sanitization methods to mitigate threats. In that case, the threats do not appear in future scans (again, the presence of the threat is not a problem since there are mitigations in place — no need to clutter analysis results with false positives).

For auditing purposes, ShiftLeft allows admins to monitor the use of interactive remediation and, if necessary, roll back changes that have been implemented to that point.

ShiftLeft provides developers with a starting point; developers can modify this file, test the changes to see what information would be suppressed, and (when appropriate) submit the config file for inclusion and use in all future ShiftLeft scans.

# Example analysis remediation config
methods:
 - method: org.slf4j.Logger.info:void(java.lang.String,java.lang.Object)
   tags:
     - key: category
       value: Sensitive Data Leak
 - pattern: Logger.debug
   tags:
     - key: category
       value: Sensitive Data Leak
- key: category
value: Sensitive Data Leak

Expanding ShiftLeft’s language support

Currently, ShiftLeft CORE supports applications written in C#, Go, Java, JavaScript/TypeScript, Python, and Scala, as well as Terraform projects and modules. SCA support is available for C#, Java, JavaScript/TypeScript, and Scala. ShiftLeft’s recent updates include SAST support for mobile apps written in Kotlin (currently in beta), as well as SCA support for apps written in Python and Go (beta).

Conclusion

ShiftLeft CORE presents you with the tools you need to provide actionable, easily digestible recommendations to your developers. It also allows you to strike the balance that best fits your organization’s needs in terms of automation and customizability when it comes to your AppSec tool, while not hindering the velocity of your developers.

If you are not yet a customer, now is a great time to check out ShiftLeft CORE. Any account created before the end of February is eligible for an extended premium trial with unlimited scans of 20 apps for 60 days!

Increasing your AppSec velocity with ShiftLeft 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 Katie Horne. Read the original post at: https://blog.shiftleft.io/increasing-your-appsec-velocity-with-shiftleft-e254c6c59a43?source=rss----86a4f941c7da---4

Katie Horne , , , ,