The data model: applications and projects in

is organized around applications and projects.

Applications

The application can be called the organizing principle of , 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 :

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.

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 :

  • 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 .
  • Branches created by (created when you run tests from your IDE).
    Note: The names of branches created by include CodeSight_ and the email address of the user the branch was created for (for example, CodeSight_user@domain.com).
    Important: Branches created with are not compatible with SCM integrations.

You can add all three types of branches to any SAST & SCA project, and can configure 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 :

  • 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.