Skip to content
Shield360 Shield360 Shield360

Code security: what shield360 scan found in your apps

Protect → Application security → Code security shows what shield360 scan found in your apps’ code and container images: known vulnerabilities in the packages they use, failed configuration checks, and committed secrets. Each finding is ranked by an exposure-weighted priority that combines the scanner’s severity with what Shield360 sees of the app at run time.

The page shows the current project’s environment only, the same one the switcher in the header shows.

Before you start

Section titled “Before you start”
  • Run shield360 scan in your app’s directory, or in CI, with SHIELD360_URL and a project API key for the environment. The key’s creator needs Manage AI app security.
  • To view the page you need View AI app security. To change a finding’s status you need Manage AI app security.
Terminal window
shield360 scan
shield360 scan ./services/orders --app orders
shield360 scan --image ghcr.io/acme/orders:1.4.2

When the scan finishes, the CLI prints a link to /security/code?scan=<id>. That link opens Findings on that scan, with its target, time, commit and branch.

Your code never leaves the machine. Shield360 receives package names and versions, advisory IDs, check results and the file each was found in. A secret arrives as its rule, file and line only, so the page cannot show its value.

For a directory, shield360 scan also checks the app’s own code with Shield360’s code rules. A code finding is sent as its rule, file and lines, with no code, and is listed here with the kind Code. Open the file at that line to see the code.

Findings

Section titled “Findings”

Each target (an app’s directory, image, or another target type a scanner reports) keeps the findings of its latest scan. The list shows open findings first, then the highest priority.

FilterWhat it does
AppOne app’s findings
Target typeDirectory, image, or another type a scanner reports
KindVulnerability, misconfiguration, secret or code (a code rule finding)
SeverityThe scanner’s severity: critical, high, medium, low or unknown
StatusOpen, fixed or accepted risk
AI components onlyVulnerabilities in model SDKs, agent frameworks, MCP SDKs, model runtimes and vector stores, and findings of the AI code rules (ai.*, py.ai.*)
Fix availableVulnerabilities whose advisory names a fixed version

The list shows the 1,000 worst findings that match. Filter by app, kind or severity to see the rest.

Select a finding to see its details:

  • the advisory ID and its aliases (CVE, GHSA), title, CVSS score, CWE and publication date;
  • the package, the installed version and the fixed version;
  • the file and line, and how to fix a failed check;
  • when this environment first saw it. Shield360 carries the first sighting forward on each new scan, so it survives upgrades that leave the finding in place;
  • other apps whose latest scans report the same advisory in the same package (or the same check). Secrets are never matched across apps;
  • the app’s exposure and the factors that set its priority;
  • its status and a note.

Status

Section titled “Status”

Set a finding to Open, Fixed or Accepted risk, with an optional note of up to 500 characters. The status is kept per environment by the finding’s fingerprint (kind, app, rule, package and file, without the version; for a code finding, the rule, file and a hash of the matched code, so it survives the code moving to another line), so it stays in place on the next scan. Each change is recorded in the audit log with the status before and after.

Priority

Section titled “Priority”

The priority starts from the scanner’s severity and moves with what Shield360 already observes of the app. A signal that could not be read changes nothing, and the page says which signals were missing.

FactorPointsRead from
Base: critical, high, medium, unknown, low70, 50, 30, 20, 10The scan
The app sent traces in the last 7 days+15Spans whose service.name is the app
The app sent no traces in the last 7 days-10The same spans
Runtime protection reported attacks on the app in the last 7 days+15Runtime protection events
Passive IAST reported a vulnerability in the app in the last 30 days+5Vulnerabilities
A Shield360 Edge instance that checked in during the last 24 hours routes the app (not for secrets)-5Edge heartbeats
The vulnerable package is an AI component+10The scan
A fixed version exists+5The scan

The score is kept between 0 and 100. P1 is 80 or more, P2 60 or more, P3 35 or more, and P4 anything lower.

For example, a critical vulnerability in an AI SDK of an app that sent traces this week scores 70 + 15 + 10 = 95 (P1). The same vulnerability in an app that sent no traces scores 70 − 10 + 10 = 70 (P2).

Some limits to keep in mind:

  • An app matches traces and runtime protection by name. Name the scan with --app the same way the app’s SDK names its service.
  • Behind Edge means an Edge instance has a route by the app’s name. Edge names a route’s app after the route by default. It does not mean the Edge WAF is on for that route.
  • Traces are read for 7 days only, so the score is cheap to work out. Exposure results are kept for 5 minutes per environment.

Scans

Section titled “Scans”

Scans lists every scanned target with how many scans it has and when it was last scanned. Select a target to see its history, newest first: the time, commit and branch of each scan, and its counts of vulnerabilities by severity, failed checks, secrets, code findings and components. A chart shows critical and high vulnerabilities over the last 30 scans.

Shield360 keeps the counts of up to 100 scans per target. Only the latest scan keeps its findings and components. Show findings opens that scan’s findings.

Components

Section titled “Components”

Components lists the packages the latest scans found, with AI components first and marked AI. Filter by app, search by package name, or show AI components only.

Download CycloneDX (in Scans, per target) downloads the latest scan of that target as a CycloneDX 1.5 JSON file. It contains the target, the components with their package URLs, and the vulnerabilities found in them, each linked to its component. AI components carry the property shield360:ai_component. Misconfigurations and secrets are not part of a bill of materials, so the file leaves them out. Each download is recorded as data access.

Repositories

Section titled “Repositories”

Repositories scans connected GitHub repositories’ lock and manifest files every day for vulnerable packages, without running shield360 scan. Each repository is off until you turn it on.

To add a repository:

  1. Choose Add repository. You need permission to create connectors; without it the button is hidden.
  2. In the connector dialog, enter the repository URL (https://github.com/owner/repo, with /tree/<branch> to pin a branch). For a private repository, add a GitHub token that can read its contents. A fine-grained token with Contents: Read-only on that repository is enough. See Scanner connectors for the fields.
  3. Save. The repository appears in the list. Turn Dependency scanning on to run a first scan.

The repository is a scanner connector of the current project and environment, so it also appears under Settings → Connectors, where you can edit or remove it.

Only the lock and manifest files are read, through GitHub’s API with the connector’s token. Nothing is cloned and the files are not kept: Shield360 stores the package names and versions and the file each came from. The findings appear under Findings with the target type Repository. When the branch has not moved since the last scan, the stored package list is matched again against new advisories without reading GitHub. Turning scanning off deletes what its scans stored.

API

Section titled “API”

All routes act on the caller’s current environment. Nothing in the request can name another environment.

RoutePermissionWhat it answers
GET /api/code-security/findingsView AI app securityFindings with status and priority. Query: app, targetType, kind, severity, status, ai=1, fix=1, scan
GET /api/code-security/findings/{fingerprint}View AI app securityOne finding, where else it is, and its app’s exposure
PUT /api/code-security/findingsManage AI app securitySets { fingerprint, status, note? }
GET /api/code-security/historyView AI app securityTargets and scan history. Query: app, targetType, targetName, scan
GET /api/code-security/componentsView AI app securityComponents. Query: app, ai=1, q, scan
GET /api/code-security/components/export?scan=<id>View AI app securityThe scan’s CycloneDX 1.5 JSON

Governance

Section titled “Governance”

Scans also feed governance:

  • AI inventory. Each app whose latest scan lists AI components gets Found in code evidence in the AI inventory.
  • Controls. Two control checks read the latest scans:
    • AI components in apps’ code are recorded by a current scan backs ISO/IEC 42001 A.4.4.
    • Critical and high findings in scanned code are triaged backs A.6.2.4. It is a gap when a critical or high vulnerability or code finding, or a committed secret, stays open for more than 30 days after it was first seen.

Next steps

Section titled “Next steps”