Manage applications and shared sources

Use Applications to describe the software you operate and the repository references that make up each environment. Applications are available on Starter, Pro and Team. Tracked-branch, people, automation and AI limits depend on your plan.

Verified on October 11, 2026. Check that your instance includes the Applications update. Examples below are fictional.

Create an application

A member or administrator can create an application. A viewer can read existing applications; a member or administrator must configure an empty workspace. Signing in opens Applications. On your first arrival in an empty workspace, the creation form opens automatically. Cancelling stores no draft and does not reopen it repeatedly. Use Create application to start again.

1. Enter Name, a description and the Production declarations. Internet facing and Customer data describe this environment, not all uses of a shared repository.
2. Select repositories and choose Branch or Tag. Focus the reference field to see discovered names; typing filters this list without changing the case of the selected name. Click a suggestion or use the arrow keys and Enter. Escape closes the list. You can also enter an exact name absent from the list. You can connect and import repositories while keeping the form open. Connection/import prepares the repository catalog; it does not start a source scan.
3. Review Production and its references, then click Create application.

Creation saves the application, Production and their associations together. A newly followed source receives one initial background scan, including on Starter. Another application using that source reuses its results and does not receive a second initial scan. Creation does not consume the manual organization scan allowance. Without a complete result, the application shows an unavailable score and its scan state.

The same reference picker is available when attaching a source in application details. Changing the repository or reference type clears that field. Discovery does not scan the repository and may be incomplete or unavailable; loading, empty results and errors still allow manual entry. A manually entered name is not proof that the reference exists.

Reference names are literal and case-sensitive. A branch and a tag with the same name are separate sources. Each environment can use only one reference per repository. The same source can belong to several applications or environments in your workspace; sources are never shared between workspaces.

Read posture and scoped results

Application details select Production by default. Findings, Update queue and Inventory links preserve the application and named environment. These pages also let you choose an application, Production/non-production/all environments, or a named environment. Their scope is kept in the URL.

Overview shows the union of Production sources. Its score is calculated on that union, not by averaging application scores. A technical occurrence shared by two applications appears in both groups but contributes once to the transverse total. Group counts overlap and must not be added together.

The posture scale is 0–100; higher means healthier under the existing posture formula. Each score identifies its scope, result date and scope version. The calculation version is not shown in the product. A missing result, incomplete coverage or an empty Production blocks the score. Unsupported sources are identified separately; an entirely unevaluable scope never receives a healthy score merely because no findings were returned. Docker base-image support and pinning checks remain inventory evidence; they are not a Docker CVE scan or a new security score.

A source scan resolves its branch/tag to a commit once and reads that immutable content. Evidence identifies the reference, commit, file and result date. A queued or running scan does not make older results more recent. History records analysis results, scope changes and local decisions separately.

The search in the application header finds source findings and inventory packages. A current result opens its application and named environment; accepted findings remain searchable and open with Accepted risks selected. Repository counters reflect open Production findings and identify unavailable or historical results.

Handle source errors and moved tags

Following a complete scan, a source failure can reuse that complete result for three days from the first failure. The error remains visible. Retries do not extend this period. Grace cannot reuse a different reference, a previous orphan period or a moved tag. During those three days, members and administrators can Reconnect the repository. Reconnecting repairs provider access; it does not prove that a new scan has completed. After expiry the affected environment and Production portfolio have no current score; individually covered applications remain visible. Reconnect and Remove then appear beside the error. Remove detaches that association. Other applications that still use the source keep it. A viewer sees the error without these actions.

A moved tag blocks the new content before analysis. The status reads The tag changed commit. A member or administrator can preview the freshly resolved commit and all affected environments, then choose Scan the new commit or Not now. Not now leaves the previous commit in place. Confirmation is audited and validates that the reference, connection and associations still match the preview. If something changed, preview again. A viewer cannot confirm a tag move.

Accept and restore risk locally

Fix now, Plan and Monitor are automatic categories. Monitor is a recommendation to observe/defer; it does not accept, hide or resolve risk.

Accept risk is a human decision for one finding in one application environment and source. It excludes that occurrence from the local posture and records the actor and date. Select Accepted risks to view such decisions and use Restore to reopen the local risk while the finding is still present. The automatic category filter is separate from this decision filter.

For example, fictional Payments and Portal share example/api, branch main. They show one common technical finding. Accepting it in Payments removes it from Payments’ score, while Portal and the global Production score still include it. Accepting it in both removes it from the global score. Restoring it in either includes it again. A later reappearance after confirmed disappearance starts a new episode, with risk open again. Decisions do not transfer to another ref.

The 0–100 Rank orders work; it is different from posture and technical risk. Declared context adds Production +8 or non-production −8, Internet exposure +6 and customer data +6, with the existing clamps. Eligible paid AI refines that rank within its rule-based category using the existing −30 to +30 bound and confidence checks. One current decision is reused for a shared occurrence and actual context profile. At most eight profiles exist; application names and identities are not provider inputs. Adding an application with an existing profile does not multiply calls. Unavailable reviews, outdated decisions, and reviews that keep the order stay ranked by rules. Opening Applications on Starter does not enable paid AI or new automation.

Detach, delete and retain history

Remove detaches a source from the selected environment. Other associations remain. After the last detachment, pending work stops; already prepared running work may finish as historical evidence. Orphan sources are excluded from current scores and automation. Repository details retain Shared source history, including exact refs and commits. Expand a source and select View analysis to read its saved findings, inventory and updates at that commit. Use Older analyses to retrieve earlier pages. These views are read-only, accessible to viewers and do not change current scores, local decisions or scan queues. Header search also finds the latest retained results of orphan sources and opens this historical view. Reattach the exact source from an application to follow it again; this does not create another initial scan.

Only an administrator can Delete application, through the confirmation flow. This removes the application and associations while retaining source analysis history and other applications’ resources.

Export and notify

Use Export scope on Findings/Update queue for CSV and on Inventory for CycloneDX 1.5 JSON or SPDX 2.3 JSON. Exports retain technical identities, exact source/ref/commit/file/date provenance, application contexts and local decisions. A shared occurrence is exported once with its contexts. CSV escapes cells; CycloneDX properties and SPDX annotations carry provenance.

Digests and eligible alerts use open Production contexts and deduplicate shared occurrences. Accepting risk in one context does not hide an open context in another application. Existing channel configuration, plan rights, budgets and activation requirements still apply. No new notification channel is activated by creating an application.

For a source refresh, use Scan source in its environment. Organization-wide Scan all keeps its existing plan allowance, including Starter’s 24-hour manual limit. Manual source scans use the existing short-term rate limit and do not acquire that organization-wide cooldown. Scheduled scans and webhooks require active associations and obey the existing organization schedule gates.

Tracked branches and people

Your organization shares one pool: 5 tracked branches on Starter, 75 on Pro, and 300 on Team. A tracked branch is one connected repository on an exact branch or tag, attached to an application. The same reference shared by three applications counts once; two different references of the same repository count twice. A connected repository or a reference with no application association consumes no tracked-branch slot. Connecting repositories has no plan limit.

The counter in Repositories, Applications and the application wizard reports the organization’s current usage. A new association consumes a slot only when its reference is not already counted. At the limit, remove or detach a reference in Applications, or choose a larger plan in Settings → Billing. Detaching one copy of a shared reference frees a slot only after its last association is removed. Creating an application with too many new references is refused as a whole: it does not leave a partial application.

Starter includes 1 person, Pro 10 people, and Team Unlimited people. All members count, including viewers. A pending, unexpired invitation reserves a place unless its email already belongs to a member; inviting the same email again does not reserve a second place.

The scan frequencies, AI permissions and machine-access quotas remain separate from this pool. The downgrade rules below govern continued scanning of existing references.

Archiving a connected repository does not detach its application references: they continue to consume tracked-branch slots and remain visible in Applications. Remove those references directly from the relevant applications; reconnecting the repository is not required. You can also delete an application whose entire scope is no longer needed. Only removing the last association frees the slot. The untracked count excludes archived repositories and sample/seed rows; it uses the same active connected catalog as the connection dialogs.

After a plan downgrade

A scheduled cancellation keeps the current plan until the change takes effect. From that effective date, existing references have 14 days of scan grace. New references and new people immediately follow the new plan’s limits; grace never reserves extra places from the old plan.

At the end of grace, if your tracked-branch usage is above the new limit, no new automatic or manual scan starts. Queued jobs and retries also wait. A scan that started before the deadline can finish. This quota refusal does not delete a result or claim that a provider failed.

Remove or detach references in Applications until usage is at or below the new limit, or move to a plan with sufficient capacity. Scans become eligible again automatically; scheduled scans resume at their next eligible run. Archiving a repository alone does not free its associated references.

Exceeding the people limit alone does not stop scans. Existing members stay; new invitations and invitation acceptance remain subject to the new plan’s quota. Human access to results, permitted exports and cleanup actions remains available. Check result timestamps to understand their freshness.

API/MCP access follows a separate rule: Team to Pro allows 14 days of grace when more than five machine accesses are authorized. No further machine access is admitted once five slots are occupied. After grace, tokens that were already authorized keep working. A new token for that workspace stays pending until fewer than five accesses are authorized. Starter disables machine access immediately on the effective change, while retaining suspended authorizations. A later return to Pro does not start a new machine grace: calls stay blocked until usage is within the limit. Other workspaces remain governed by their own plans.