Skip to content

Getting Started

Logging into Boost and configuring your first Integration

  1. Go to, you will be redirected to Boost's login page.

  2. Enter your organization's name alias (ex. sudocorp) as provided by your Boost's account administrator.

  3. If the organization name is correctly recognized, you will be prompted to select your authentication method (ex. Google or GitHub).

  4. Once logged in, you will be redirected again to the Boost dashboard at

  5. In the left-hand side navigation menu, select Integrations.

  6. In the Available tab of the Integrations page, click Install button to the right of GitHub.

  7. You will be redirected to GitHub, where you will need to be logged in as an GitHub Organization Owner in order to complete installing the integration.

  8. GitHub will prompt you to install the GitHub App. You must select an organization and then select either All repositories or Only select repositories. You will need accept the permissions request by clicking Install & Authorize.

  9. You will then be redirected back to the Integrations page and should be able to confirm that the GitHub organization is now bound to your Boost account.

  10. At this point, you can configure the following data feeds into the platform:

    • Toggle the Dependabot switch to enable a periodic synchronization of vulnerable dependencies detected by Dependabot (Ensure that Dependabot is enabled in Github for the repositories you want to be scanned).
    • Toggle the CI-CD switch to enable a periodic security posture evaluation of your GitHub Organization and Repositories.
    • Configure your CI system to use the BoostSecurity Scanner to push findings related to your source code.

Exploring the Findings page

Once Boost starts to receive data feeds, you can explore the results in the Findings page.

You can filter and drill-down through the findings using the drop-down menus and toggle switches at the top of the page.

This allows you to focus on findings from one or more project(s) (i.e. GitHub repositories) or that were triggered by a specific scanner rule.

For each finding in this page, you can see the rule that detected the finding, the file path and source code lines where it was found as well as a description and link to the documentation giving more explanation about why this is an issue and how to address it.

Policies and Violations

By default, Boost scans will produce findings in a non-blocking, non-invasive way for developers. Findings are displayed in Boost's dashboard so that security teams can explore issues.

A Boost policy allows your security team to define what types of findings are important to them. On the Policy page you can configure what should cause a finding to be a violation. Violations are tracked separately in Boost so you can easily see where repositories are in violation with your policy.

The policy also lets you enable actions when violations occur. These actions can be to alert a developer by adding a comment in a pull request, blocking a pull request from merging, or send a Slack message to a specific channel - just to name a few.

Developer Workflows

As an example of how you might use a policy, lets say your team is currently focused on fixing XSS issues across your organization. You may want to first warn developers for a period of time, then eventually block their build.

In the Policy page you can enable all of the rules under the XSS category and set the action to "Alert". This will enforce the policy across all new pull requests against the default branch. If a developer pushes an XSS vulnerability to their branch that is detected by the Boost Scanner, they will be presented with a comment in their pull request notifying them of the exact line the vulnerability occurred on and how to fix it. Alerts will not block pull requests, just notify developers.

When you're ready to block developers from merge pull requests when they've commit a violation, change the policy action from "Alert" to "Block". In addition to warning the developer with pull request comments, this will also fail a check in your SCM and block a pull request from being able to be merged until the violation has been fixed. Once the developer follows the steps in the linked documentation to fix the vulnerability, Boost will detect the violation has been resolved and unblock the pull request.