Preparation is key for a successful rollout of ShiftLeft CORE and reduces the likelihood of early issues and friction commonly associated with automated scanning tools. The objective of the preparation phase is to provide the users of ShiftLeft guidance and examples to perform internal discovery and information gathering.
CI/CD workflow integration
ShiftLeft CORE is optimized for integration with CI/CD tools such as Jenkins, Azure DevOps, and GitLab. The most common approach is to use the developer pipeline for code analysis, too, but you could have a dedicated CI/CD setup for AppSec and compliance purposes or to combine the two options. The table below summarizes the two distinct use cases:
|Developer CI/CD Integration||Dedicated AppSec CI/CD integration|
|Purpose||Security testing encourages software teams to resolve issues in the development process||Facilitates supplier assurance testing to evaluate work produced by third-party supplier/teams|
|Suitability||For applications or microservices that can be scanned in minutes||For aggregate microservices that require a thorough combined analysis or monorepos|
|Customization||Development (or AppSec) teams can set build rules and scan policies||AppSec teams can control scan policies and configurations for compliance purposes|
CI/CD build image
Enterprise CI/CD platforms, such as Jenkins, GitLab, and GitHub Enterprise, support the use of custom Docker build images. You can include ShiftLeft as part of a custom image, though the instructions for doing so differ depending on the base image used.
The base image you can use depends on the application language. For example, Ubuntu, Debian, and RedHat images are well-supported, but the Alpine image cannot be used with Python or Infrastructure-as-Code languages.
Please work with your ShiftLeft customer success representative while developing the custom build images.
Over the years, we've observed three primary types of ShiftLeft workflow integration, each based on the engineering team's development and release model.
Small teams and those with small repositories containing the source code for new upcoming applications prefer a trunk-based development model.
You can configure ShiftLeft to scan every commit for such teams, as long as the scan times do not affect the engineers' velocity.
This is the most common integration model. Engineers work on new features and updates in separate feature branches. You can configure ShiftLeft to scan the pull requests before engineers merge them into the main branch.
In addition to scanning individual pull requests, you can configure ShiftLeft to periodically scan the main branch. Doing so helps establish a baseline for comparison purposes.
For example, the engineering or AppSec team could scan the main branch and any existing vulnerabilities that ShiftLeft identifies could be treated as technical debt; the team could then configure ShiftLeft to only look for and report newly introduced vulnerabilities.
The ShiftLeft customer success team can help you set up the baseline during as part of your Week 1 and Week 4 activities.
Teams following advanced development workflows, such as those prescribed by Git, can scan their application whenever specific events occur, such as the opening of a pull request or the creation of a release.
Depending on the size and complexity of your applications, you could configure ShiftLeft to operate in a fast-then-slow fashion: ShiftLeft can be used to perform a quick focused scan when engineers want to merge in changes and for a fuller, deep scan just before software releases.
Users and single sign-on (SSO)
ShiftLeft CORE supports well-known SAML 2.0-based single-sign on (SSO) providers, such as Azure Active Directory, Okta, and OneLogin with just-in-time (JIT) provisioning.
You will need to decide on an authentication and authorization strategy that is appropriate for your organization. To do so:
Decide on an owner; this person will own the root account for your organization. This person is typically the Head of Application Security or the Security Director responsible for sponsoring the InfoSec or AppSec programs.
Nominate and invite a handful of users to act as super admins and power users.
Create users and teams for your organization; Super Admins can do this using the ShiftLeft UI or the integration scripts leveraging the ShiftLeft API. See the following section of this guide for an example of how you might map existing groups and roles to your ShiftLeft organization.
To help with the automated provisioning of users, we recommend creating a spreadsheet that details the teams needed, as well as the users and the roles they need:
Team name Role(s) email@example.com api-team Team Member firstname.lastname@example.org ui-team Team Admin email@example.com security-team Org Member, Super Admin, Power User
Invite your users to log in to ShiftLeft. Their accounts will be automatically created and provided the default role of member. We recommend that you send information to all users to introduce ShiftLeft CORE and provide them with the organization contact if they have questions or need assistance.
Mapping existing organization roles and groups to ShiftLeft roles and teams
Though you can only have one org owner for your ShiftLeft organization, you can have multiple super admins and power users in your organization to add and create applications and teams. Within a team, you can have guests (read-only users), members (developers), or admins (managers or architects).
Below is a sample organizational hierarchy, along with the equivalent ShiftLeft roles.
You can make use of the automation script provided by ShiftLeft to avoid any errors during the creation of teams and roles.
Integrating ShiftLeft into your CI/CD platform results in applications and application groups (which are simply two or more applications grouped together in ShiftLeft) automatically created for your organization. However, we recommend a phased rollout for ShiftLeft to better manage the deployment workload for contributors.
To integrate ShiftLeft with your CI/CD platform, use integration tokens instead of user access tokens. Super admins can create integration tokens, which are assigned an organization scope.
Before making any decisions, create a spreadsheet of all your applications, as shown below:
|App name||Team name (app group)||CI/CD system||Integration mode||Risk profile|
An application might include multiple repositories and internal dependencies, so it is essential to list the application names, not just the repository names.
Based on your applications list, decide on a phased roll-out strategy. For example, you might decide to proceed based on:
- The application risk profile (applications with the highest risk profile first)
- Team affinity (certain teams would adopt ShiftLeft first)
- Workload (application with low release/maintenance needs first)
ShiftLeft also supports the use of app groups. App groups allow you to collect applications that share a common thread (e.g., you might create an app group to collect all the applications that are for internal use only and name it
internal-apps). App groups are displayed together in the dashboard, making it easy for users to see only relevant applications. You can group apps using both the ShiftLeft CLI and dashboard.
Security Champions and a community of practice
In a large organization, the security team may not be able to support the needs of every technical team. As such, we recommend implementing a “train the trainers” approach to increase the number of those with knowledge of application security and how to work with ShiftLeft.
Each dev/technical team should nominate someone to be that team's security champion and act as the key point of contact between their team and the security team. Security champions, who do not need to have programming experience, would participate in the initial onboarding and training sessions.
We also recommend connection security champions via Slack, a teams-only channel, and/or an internal wiki to capture and share the knowledge about internal systems, their configurations, and security policies.
|DevOps||Identify the CI/CD platform, OS, and build image requirements|
|AppSec||Plan internal communication to introduce ShiftLeft to users|
|AD/IAM administrator||Review the documentation and API required for setting up SSO|
|AppSec||Work with development managers to prepare the list of users and team names for ShiftLeft|
|AppSec||Prepare the list of applications and integration mode by using data sources such as Git, CMDB etc.|
|AppSec||Identify a rollout approach for applications based on suitable criteria|
|IT||Configure the antivirus software, firewall, and proxy server to allow build agents to communicate with ShiftLeft servers|
|AppSec||Identify security champions and introduce them to ShiftLeft|