Scenario 20: Dependency analysis

Choose a surface

Run a bounded CLI check

Run from the checkout whose dependency manifests you intend to inspect:

python -m src.cli deps scan PATH --include-dev --max-depth 10
python -m src.cli deps check-vulns --path PATH --severity medium --fail-on high --output vulnerabilities.json

scan recognizes the manifest families implemented by the current parsers. check-vulns builds a fresh graph for PATH, applies the requested scope and writes JSON only when --output is present. Record the checkout revision, path, include-dev/direct/depth/package limits, ecosystem override, severity threshold and command exit code with the artifact.

Other registered commands provide different evidence:

python -m src.cli deps list --direct --format json
python -m src.cli deps graph --format mermaid --depth 3 --output dependencies.mmd
python -m src.cli deps licenses --check-compliance --allow MIT Apache-2.0 --deny GPL-3.0
python -m src.cli deps health
python -m src.cli deps update --conservative

The license allow/deny set is an operator input; legal policy comes from the accountable legal review. deps update prints suggestions and leaves the manifest and lock file unchanged. Health is a heuristic calculated from the observed graph; the release verdict is recorded separately.

Account for network, cache, and freshness

The vulnerability checker uses OSV by default. An OSV lookup requires outbound network access unless a matching cache entry is available. The registered-project REST path can be configured with additional sources; GitHub Advisory needs GITHUB_TOKEN, while NVD needs NVD_API_KEY. Do not describe those sources as active merely because their implementations exist.

Record enabled sources, external timeout, cache path, cache TTL, cache hit age, query time and any feed warning. A network or credential failure can yield no vulnerability findings after a warning; record the feed warning with the result. Fail closed when feed provenance or freshness cannot be demonstrated.

Use the registered-project REST API

The current router is mounted below /api/v1/security/sca and requires an existing project registration with a valid source root. The principal read routes are:

• GET /api/v1/security/sca/projects/{project_name}/summary;
• GET /api/v1/security/sca/projects/{project_name}/dependencies;
• GET /api/v1/security/sca/projects/{project_name}/vulnerabilities;
• GET /api/v1/security/sca/projects/{project_name}/sbom.

Treat 404 as an unknown project, 409 as incomplete project configuration, and scan or feed errors as failed evidence collection. Preserve the response together with the registered project identity and revision basis.

Run the typed AppSec scenario

from src.digital_employees.runtime.scenarios import (
    RoleBoundScenarioInvocationRequest,
    invoke_role_bound_scenario_request,
)

request = RoleBoundScenarioInvocationRequest(
    query="Analyze dependency, vulnerability, license, and SBOM risk for the bounded project.",
    employee_id="codegraph_appsec",
    scenario_id="scenario_20",
    event_type="appsec_start",
    context={
        "project_key": "codegraph",
        "namespace": "default",
        "task_id": "<task-id>",
        "source_refs": ["<revision-ref>", "<dependency-artifact-ref>"],
    },
)
result = invoke_role_bound_scenario_request(request)

Scenario 20 is conditional AppSec analysis. Its findings require triage, false-positive disposition, remediation evidence, and an accountable security decision. Product acceptance and release authorization use their own evidence.