feat(sbom): add 'Cloud Run' deployment platform marker (#220)

[nikhilpatidar]

PR Type

• Bug fix
• Feature

What

Adds a more specific Cloud Run deployment-platform marker alongside
the existing coarse GCP marker. The marker fires when any of:

• the Knative Cloud Run service API appears in a YAML manifest
  (apiVersion: serving.knative.dev/v1),
• the official google-github-actions/deploy-cloudrun GitHub Actions
  step appears in a workflow,
• any run.googleapis.com annotation is present,
• a *.a.run.app runtime URL appears in the file content, or
• a file path contains the substring cloudrun.

Why

Issue #220 reports that nuguard's GCP discovery is too coarse. The
existing GCP marker fires for any GCP-related content (gcloud, Cloud
Functions, Vertex AI, generic gcr.io references) without
distinguishing Cloud Run, which is the most common serverless
deployment target for AI apps today. Downstream analyzers and reports
that want to surface Cloud Run-specific concerns (e.g. unauthenticated
invoke URLs, IAM conditions for service-to-service calls) had no
programmatic way to tell those scans apart from generic GCP scans.

Root cause

extract_deployment_context in
nuguard/sbom/core/application_summary.py had no Cloud Run-specific
trigger. The coarse GCP marker fired on gcloud, cloud run,
cloudrun, vertex ai, etc. but those inputs are also common for
non-Cloud-Run GCP services, so a downstream consumer cannot tell which
deployment target is actually in use.

Changes

• nuguard/sbom/core/application_summary.py — adds a second platform
  block in extract_deployment_context that appends Cloud Run to the
  platform list when any of the five triggers above fire.
• tests/sbom/test_cloud_run_detection.py — 6 new regression tests
  pinning the contract end-to-end through
  extract_deployment_context:
  • Knative Service YAML → Cloud Run + GCP + Kubernetes
  • Deduplication when multiple triggers fire
  • GitHub Actions deploy-cloudrun step → Cloud Run + GCP +
    GitHub Actions
  • *.a.run.app URLs captured as deployment_urls
  • File path with cloudrun substring triggers the marker
  • Negative: plain Kubernetes manifest is NOT marked as
    Cloud Run (so we don't over-fire)

Tests

• tests/sbom/test_cloud_run_detection.py: 6 new tests, all passing.
• tests/sbom/ full suite: 188 tests passing.
• ruff check clean.
• mypy clean on the touched module.

Backward compatibility

• The GCP marker continues to fire in parallel — Cloud Run is a
  strict subset of GCP, so downstream consumers reading GCP keep
  working.
• Platforms are already deduplicated by the existing _uniq(...) call
  on the platform list, so a single scan produces at most one
  Cloud Run and one GCP entry even when multiple triggers match.
• No public function signatures change; only the contents of one
  returned list (deployment_platforms) gain an additional possible
  entry.

What this PR does NOT do (issue #220 remains open)

This PR is the narrow, regression-pinning slice of #220 — adding the
marker and the tests. The following remain on the issue tracker for
follow-up PRs:

• Broader cookbook validation across all three clouds (Python / JS-TS /
  Go AI apps on AWS / Azure / GCP) — the request in [Feature]: Extending AI-BOM support #220's "Possible
  Solution" list.
• More sophisticated Cloud Run URL reconstruction from
  K_SERVICE / GOOGLE_CLOUD_PROJECT env vars (the GitHub Actions
  AWS App Service equivalent is implemented for Azure but not yet for
  Cloud Run).
• GCP-specific configuration scanning (e.g. cloudbuild.yaml,
  app.yaml).
• AWS and Azure parity improvements for issue [Feature]: Extending AI-BOM support #220's complaint.

This PR deliberately does not use the Closes #220 syntax,
because GitHub's auto-close behaviour does not understand the
"partial" qualification; the issue should remain open until the
broader cookbook-validation work is done.

Addresses part of #220

[KanishkThamman]

Additive, no schema impact. One nit inline on a false-positive trigger.

[KanishkThamman]

Nit: Knative Serving is open source and commonly self-hosted on plain GKE/EKS/AKS, so this trigger alone isn't Cloud-Run-specific and could mislabel a self-hosted Knative-on-GKE deployment as "Cloud Run". Worth a negative test case.

[nikhilpatidar]

Fixed in 20c00e3. Split the Cloud Run trigger into a weak signal (the Knative service API) and a set of strong signals (deploy-cloudrun GitHub Action, run.googleapis.com annotation, *.a.run.app URL, 'cloudrun' in path). The marker now fires only when a strong signal is present, OR when the Knative service API appears together with a run.googleapis.com / *.a.run.app co-signal.

Added two tests to test_cloud_run_detection.py:

• test_self_hosted_knative_service_is_not_marked_as_cloud_run: bare Knative Service YAML without any co-signal must NOT be marked Cloud Run (the exact regression).
• test_knative_service_with_run_app_url_is_marked_as_cloud_run: Knative Service + a *.a.run.app URL in a separate file IS marked Cloud Run (pins the co-signal path).

All 6 existing tests still pass — the original positive case already includes run.googleapis.com alongside serving.knative.dev, so it satisfies the new co-signal requirement.