Planning for deployment
Preparation is key for a successful rollout of Qwiet preZero 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 Qwiet guidance and examples to perform internal discovery and information gathering.
CI/CD workflow integration
Qwiet preZero 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 Qwiet 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 Qwiet customer success representative while developing the custom build images.
Integration models
Over the years, we've observed three primary types of Qwiet workflow integration, each based on the engineering team's development and release model.
Trunk-based development
Small teams and those with small repositories containing the source code for new upcoming applications prefer a trunk-based development model.
You can configure Qwiet to scan every commit for such teams, as long as the scan times do not affect the engineers' velocity.
Feature-branch development
This is the most common integration model. Engineers work on new features and updates in separate feature branches. You can configure Qwiet to scan the pull requests before engineers merge them into the main branch.
In addition to scanning individual pull requests, you can configure Qwiet 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 Qwiet identifies could be treated as technical debt; the team could then configure Qwiet to only look for and report newly introduced vulnerabilities.
The Qwiet customer success team can help you set up the baseline during as part of your Week 1 and Week 4 activities.
Git-flow development
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 Qwiet to operate in a fast-then-slow fashion: Qwiet 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)
Qwiet preZero 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 Qwiet UI or the integration scripts leveraging the Qwiet API. See the following section of this guide for an example of how you might map existing groups and roles to your Qwiet 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:
Email Team name Role(s) john.smith@example.com api-team Team Member alice.taylor@example.com ui-team Team Admin bob.jones@example.com security-team Org Member, Super Admin, Power User Invite your users to log in to Qwiet. Their accounts will be automatically created and provided the default role of member. We recommend that you send information to all users to introduce Qwiet preZero and provide them with the organization contact if they have questions or need assistance.
Mapping existing organization roles and groups to Qwiet roles and teams
Though you can only have one org owner for your Qwiet 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 Qwiet roles.
You can make use of the automation script provided by Qwiet to avoid any errors during the creation of teams and roles.
Applications
Integrating Qwiet into your CI/CD platform results in applications and application groups (which are simply two or more applications grouped together in Qwiet AI) automatically created for your organization. However, we recommend a phased rollout for Qwiet to better manage the deployment workload for contributors.
To integrate Qwiet 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 |
|---|---|---|---|---|
| HelloShiftLeft | api-team | Jenkins | Pull request | internal |
| sl-vue | ui-team | GitLab | Pull request | public |
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 Qwiet first)
- Workload (application with low release/maintenance needs first)
Qwiet 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 Qwiet 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 Qwiet.
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.
Planning tasks
| Stakeholder | Activity | Completed? |
|---|---|---|
| DevOps | Identify the CI/CD platform, OS, and build image requirements | |
| AppSec | Plan internal communication to introduce Qwiet 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 Qwiet | |
| 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 Qwiet servers | |
| AppSec | Identify security champions and introduce them to Qwiet |