Using the console

A tour of the web console for the people who use it day to day. For installing it see Deploying dpndncY.

The left rail has six sections; each shows its pages as tabs across the top. The top bar has search (Ctrl+K jumps to anything), the theme switch, New scan, and your account menu. If you belong to more than one organisation, a workspace switcher in the top bar changes which one you are looking at.

#Home

The Dashboard shows what needs attention across all your projects: open findings by severity, the newest scans, projects at risk, and trends.

#Projects

• Projects lists every project with its latest scan and finding counts. A project appears automatically the first time a scan with its name arrives, from the console, the CLI or a pipeline. Registering a project yourself lets you choose a repository to rescan on a schedule.
• Scans is the history of every scan, with status, engines and verdict. Open one for its findings, dependencies, licences, code findings, secrets, attack paths and AI risk, each on its own tab.

New scan starts a scan of a Git repository, an uploaded archive, a local folder (through the CLI) or a container image.

#Findings

• Findings is every vulnerable dependency across projects, filterable by severity, ecosystem, exploitability and fix availability. Each finding shows why it matters and the version that fixes it.
• Attack paths ranks routes an attacker could follow from your application's entry points, through code that uses a vulnerable package, into risky code. It shows a graph you can explore (hover to trace a chain, click to select, double-click a package to focus, scroll to zoom), a "fix these first" list of the code locations that break the most paths, and for the selected path: why it ranks there, the evidence, and how to fix it. A path is a ranked lead, not proof of exploitation.
• AI risk shows which files carry evidence of AI authorship (an AI marker inside the file, or AI tooling in its git history) and what they import. The risk radar plots every file by the vulnerable packages it imports and the risky code in it; the top right is where to start. Click a bubble or a row for the file's detail: who wrote it, the vulnerable packages it imports with the version to upgrade to, and the risky code with a few lines around each spot.
• Custom advisories lets you record vulnerabilities your own team knows about that public databases do not.
• Remediation suggestions proposes dependency upgrades.

#Protect

• Firewall decides whether a new dependency may enter your code: Decisions is the log, Policies shows the active admission policy in plain language with what it would have stopped, and Admission shows reviews of dependency changes. See Dependency Admission / Firewall Events.
• Runtime lists the runners with the runtime agent installed and the signed traces of what they did.
• Pipeline evaluates the third-party actions your workflows use (dpndncY Pipeline Trust Firewall).

#Reports

• SBOM exports downloads software bills of materials (CycloneDX, SPDX) and the PDF report centre: executive summary, vulnerability report, compliance evidence and licence report.
• Trends shows risk over time.
• Attestations shows signed evidence of scans and runtime traces.

#Settings

• General: your profile, two-step verification, API tokens, and, for owners and admins, users and roles and the sign-in security setting that enforces two-step verification for everyone.
• Integrations: Jira, Linear, webhooks (Slack, Teams, Discord and generic).
• Scan policy: choose the rulebook scans are judged against, or build your own (Scan policies).
• Scan settings and License.
• System health: queue, resources and component status.

Platform operators also see Customers (create and manage tenants) and Activity (the audit log) here.

#What your role allows

If an owner has limited which projects you see, you see only those everywhere: dashboard, findings, scans and reports (Project access).