This guide walks you through the steps needed to ensure that you're ready to set up and integrate ShiftLeft CORE's NG SAST for code analysis. This guide will also briefly cover user access, firewall modifications, and NG SAST customization.
Before You Start
Before integrating NG SAST into your software deployment pipelines, there are several things you should consider:
Applications: Decide which applications you will scan with NG SAST. For each application that you're scanning, make sure you have and can access its code repository.
We recommend prioritizing your applications based on their risk profiles or business criticality; prioritize those with the highest impact should a security issue occur for NG SAST integration.
Users: Decide who you want to be involved with the code analysis process and whether each person should be a ShiftLeft administrator or collaborator. You'll also need to decide how these users access ShiftLeft (i.e., you could implement SSO and let anyone with the appropriate email address self-enroll as a collaborator).
Instead of onboarding all users simultaneously, we recommend inviting users based on the apps you've integrated. For example, if you're scanning
public-repo-2, only invite those who interact with these two repos; as you add more apps, invite more users (if necessary).
CI/CD Platform: If you already have a CI/CD platform with which you want to integrate NG SAST (i.e., you can run NG SAST as a Jenkins post-build action), be sure you can access it and are familiar with how to modify its configuration. If not, decide on the CI/CD platform that best meets your build and deployment needs. Keep in mind that you can use different options for different stages; for example, a company might choose to use Jenkins for development and GitHub Actions for integration with NG SAST.
Software Development Life Cycle: There are two parts to this step. First, determine where in your software development life cycle SDLC)/security process you want NG SAST to run. For example, will NG SAST run as part of the build process itself, or will it be a part of the post-build process?
Second, when do you want NG SAST to run? Will you scan all pull requests/merge requests, or will you only scan your main/master branch? You could also choose to scan based on whether you consider a change to be a fix or a new feature.
Please note that how you integrate NG SAST may depend on your application language. For example, Java applications require NG SAST to be added as a post-build action, while other languages are more flexible.
Step 1: Configure Access to ShiftLeft
You can view the results generated by NG SAST in the ShiftLeft Dashboard. To that end, you'll need to add administrators manually. You can also manually add collaborators, but we recommend implementing SSO so that individual users can auto-enroll as collaborator (see User Roles and API Access Keys for information about how these two roles differ).
Currently, ShiftLeft supports SSO integrations with providers supporting the SAML v2.0 protocol.
Step 2: Integrate NG SAST
Once you've set up your users and their access to ShiftLeft, you'll need to integrate NG SAST into your application build/deployment workflow. This process requires you to download the ShiftLeft CLI and install NG SAST.
Once installed, you can check to see if your environment is ready to run NG SAST using
We also offer Terraform modules and scripts that aid with the integration and deployment of NG SAST to all of your Git repositories hosted by:
- Azure DevOps
If you're not a Terraform user, but you would like assistance with automated deployment, please contact ShiftLeft for further information.
Configure Your Firewall
If necessary, configure your firewall to allow access to the following domains (all use TCP ports 80 and 443):
These domain names are required for NG SAST to function correctly.
Step 3: Configure NG SAST and Implement Build Rules
If you want to customize the behavior of NG SAST, you can create, define, and add the ShiftLeft config file to your code repositories.
Furthermore, NG SAST relies on build rules that you define to determine if the build should fail; NG SAST makes this determination by comparing the results of its analyses against your build rules.
Once you define your build rules (we have a template you can use to get started), you can include a copy of the build rules config file (which is named shiftleft.yml) into the root of your repos.
We recommend creating a security group within your overarching GitHub organization that includes only your application security personnel. You can assign this group the privileges needed to modify and review changes to shiftleft.yml.