The data model: applications and projects in Polaris

Polaris is organized around applications and projects.

Applications

The application can be called the organizing principle of Polaris, because projects and subscriptions are associated with an application. An application is a collection of up to five projects (although this number varies according to the subscription purchased) and up to 1 million lines of code. Its boundaries don't have to align with the boundaries of a software product, but generally all the projects in an application have the same business purpose.

Projects

There are two types of projects in Polaris:

Project type Description
SAST & SCA A SAST & SCA project is a discrete body of code associated with a parent application. It can contain the entire application or can be one submodule in a larger application. It might correspond to one repository, but doesn't have to. Each SAST & SCA project includes a default branch, and may include more (non-default) branches. SAST and SCA tests always run on a single branch of a project (and issues captured in tests are linked to the branch and project).
DAST A DAST project is a target web-accessible application you wish to test. Generally, the target uses source code from the application's SAST & SCA projects, but it doesn't have to.
Note: See Run dynamic application security testing (DAST) on Polaris for more information.

Branches

Add branches to a SAST & SCA project to test changes as you iterate. By default, you can add 10 branches to any SAST & SCA project. There are three types of branches in Polaris:

  • Branches connected to repositories (via SCM integrations).
    Note: For more information on SCM integrations, see Integrate a SCM Repository to a Project.
  • Branches that aren't connected to repositories and only exist in Polaris.
  • Branches created by Code Sight (created when you run tests from your IDE).
    Note: The names of branches created by Code Sight include CodeSight_ and the email address of the user the branch was created for (for example, CodeSight_user@domain.com).
    Important: Branches created with Code Sight are not compatible with SCM integrations.

You can add all three types of branches to any SAST & SCA project, and can configure Polaris to automatically delete non-default branches that aren't tested for a period between 1 and 90 days.

Note: For more information, see Configure automatic branch deletion.

Policies

There are three types of policies in Polaris:

  • Issue policies: Use issue policies to automate actions when issues with specific properties are detected in a test.
    Note: For more information, see Issue policies.
  • Component policies: Use component policies to automate actions when components with specific properties are detected in an SCA test.
    Note: For more information, see Component policies.
  • Test scheduling policies: Use test scheduling policies to automate tests of SCM-integrated branches on a weekly or daily basis.
    Note: Test scheduling policies can only be used with branches connected to repositories, and cannot be assigned to DAST projects. For more information, see Test scheduling policies.

Default branches inherit their project's default policies. Non-default branches can use their project's default policies, or use different policies. If necessary, policies can be disabled on default and non-default branches.