Skip to main content
Prowler applies security-by-design across the development lifecycle. Every change passes automated checks at each stage: pre-commit hooks locally, multiple CI gates on pull requests, branch protection before merge, container scanning before publish, and registry monitoring after release. All security tooling and configuration lives in the Prowler GitHub repository: pre-commit hooks, CI/CD workflows, and Dependabot configuration.

​
Coverage

Security controls cover six domains, each detailed below:

​
CI/CD Security

Every GitHub Actions workflow uses runner hardening, pinned action versions, and audited permissions.

​
Runner Hardening With StepSecurity

  • step-security/harden-runner runs as the first step in every workflow, pinned by commit SHA.
  • Workflows are being migrated to explicit egress controls: some already declare an egress allow-list with egress-policy: block, while others still run in egress-policy: audit until their allowed endpoints are fully defined.
  • Global Block Policy (StepSecurity) blocks known-malicious domains and IP addresses across every workflow run. This protection applies even in audit mode, so workflows that have not yet moved to block still resist known-bad egress.

​
Third-Party Action Pinning

  • Every third-party action reference uses a commit SHA with the version as a comment: uses: org/action@<sha> # v1.2.3.
  • Dependabot tracks the comment and proposes SHA-pinned upgrades on a monthly cadence.

​
Workflow Permissions

  • Workflows declare permissions: {} at the top level and grant the minimum required scopes per job.
  • Code review covers permission changes; zizmor enforces the rules (see below).

​
Workflow Security Audit With Zizmor

  • zizmor audits every workflow file for known security anti-patterns. Runs on every pull request and push.
  • Triggers on every push, every pull request that touches .github/, and on a daily schedule.
  • Results upload to the GitHub Security tab via Static Analysis Results Interchange Format (SARIF).
  • Key audit rules the build gates on:
    • PWN Request (dangerous-triggers): unsafe use of pull_request_target with checked-out PR code.
    • Script Injection (template-injection): unsanitized ${{ github.event.* }} expressions in run: blocks.
    • artipacked: credential leakage through artifacts.
    • Excessive permissions (excessive-permissions): workflows with unneeded write scopes.

​
Branch Protection

Pull requests to master and the active v5.* release branches must pass several required workflows before merge. These gates prevent specific classes of supply-chain and pipeline attacks from reaching the main branch:
  • Compromised packages: the npm Package Compromised Updates and PyPI Package Compromised Updates checks (StepSecurity) fail any PR that introduces a package version present in the compromised-package feed. Layered on top of osv-scanner.
  • Premature releases: the npm Package Cooldown and PyPI Package Cooldown checks (StepSecurity) fail any PR that introduces a package version published within the cooldown window. Layered on top of pnpm’s minimumReleaseAge.
  • Workflow exploitation: the PWN Request and Script Injection checks (StepSecurity) reject the corresponding zizmor-detected anti-patterns at PR time. Layered on top of zizmor’s audit.
  • Vulnerable code or dependencies: CodeQL (UI, API, SDK), osv-scanner (SDK, API, UI), Bandit (SDK, API), and Trivy (container images) must all pass.

​
Static Application Security Testing (SAST)

Multiple SAST tools run on every push and pull request to catch vulnerabilities and code-quality issues before merge.

​
Cross-Language

  • CodeQL: semantic code analysis for the UI (JavaScript/TypeScript), API (Python), and SDK (Python). Runs on every push and pull request, plus a daily scheduled scan. Results upload to the GitHub Security tab via SARIF.

​
Python (SDK + API)

  • Bandit: detects common Python security issues (SQL injection, hardcoded credentials, insecure deserialization). Runs in pre-commit and on every pull request and push.
  • Pylint: analyzes your code without actually running it. It checks for errors, enforces a coding standard, looks for code smells, and can suggest refactors. Runs in pre-commit and on every pull request and push.
  • Vulture: dead-code detection at --min-confidence 100. Unused code can hide incomplete implementations or stale security paths. Runs in pre-commit and on every pull request and push.
  • Flake8: style and correctness checks for the SDK. Runs in pre-commit and on every pull request and push.

​
JavaScript/TypeScript (UI)

  • TypeScript (tsc): strict type checking for the UI. Catches whole classes of null/undefined and type-confusion bugs at build time. Runs on every pull request and push via pnpm run healthcheck.
  • ESLint: UI linting with a capped warning budget (--max-warnings 40). Runs on every pull request and push via pnpm run healthcheck.
  • Knip: dead-code and unused-export detection for the UI. The UI analogue to Vulture.
Knip runs locally on demand via pnpm run lint:knip and is not yet wired into CI.

​
Shell

  • Shellcheck: correctness and security checks for shell scripts in .github/scripts/ and scripts/. Runs in pre-commit on staged files.

​
Software Composition Analysis (SCA)

Dependencies are scanned against public vulnerability databases on every pull request and push, with results posted directly on the PR.

​
Cross-Language

  • osv-scanner: scans lockfiles against the OSV.dev vulnerability database for SDK (uv.lock), API (api/uv.lock), and UI (ui/pnpm-lock.yaml). Runs on every pull request and push.
    • The action installs the osv-scanner binary and verifies its SHA-256 checksum against the upstream-signed SHA256SUMS manifest before running. Any mismatch aborts the scan.
    • Gates the build on HIGH, CRITICAL, and UNKNOWN severity findings.
    • Posts and updates a per-lockfile report as a pull request comment.
    • Per-vulnerability ignores live in osv-scanner.toml at the repo root, each with a reason and an expiry date.
  • Trivy: scans container images for OS-package and application-dependency vulnerabilities. Runs on every pull request and push that touches an image or its dependencies. Trivy uploads SARIF to the GitHub Security tab and posts a scan summary on the PR.
  • Dependabot: configured for monthly updates of the SDK Python dependencies, GitHub Actions, Docker base images, and pre-commit hooks. Dependabot opens pull requests for known security advisories, so critical patches reach the team without delay. A 7-day default cooldown reduces exposure to compromised package releases.
  • Renovate: configured dependency update automation is transitioning from Dependabot to Renovate to gain finer control over update cadence, grouping, and per-component scope. Both tools currently run in parallel during the migration.

​
Renovate (Primary)

Configuration: .github/renovate.json
  • Coverage: Python (SDK, API, MCP Server), npm (UI), GitHub Actions, Docker images, and Pre-commit hooks
  • Range Strategy: Versions are pinned to ensure reproducible builds
  • Vulnerability Alerts: GitHub Security Advisories generate immediate pull requests that bypass rate limits and scheduled windows, labeled security for prioritized triage

​
Dependabot (Legacy)

Configuration: .github/dependabot.yml Dependabot remains active for the SDK and shared automation ecosystems until the Renovate migration completes:
  • Python (pip): Monthly updates for SDK
  • GitHub Actions: Monthly updates for workflow dependencies
  • Docker: Monthly updates for base images
  • Pre-commit: Monthly updates for hook revisions
Dependabot is paused for the API and UI; Renovate now handles those components. Even when paused, Dependabot continues to open pull requests for security vulnerabilities, ensuring critical patches are never delayed.

​
JavaScript/TypeScript (UI)

  • pnpm audit: runs pnpm audit --audit-level critical on every UI pull request and push as part of pnpm run audit. Cross-checks the npm registry’s advisory database in addition to the OSV scan and surfaces npm-specific advisories that may not yet have an OSV identifier.

​
Supply-Chain Pinning

Pinning runs across Python, npm, GitHub Actions, and container base images. Every install resolves to the exact set of versions already vetted in CI, and any drift fails loudly instead of slipping in silently.

​
Python (uv)

The SDK, API, and MCP Server all use uv for dependency management. Each component has its own project manifest and lock file: The controls applied across all three:
  • Direct dependencies pinned to exact versions (==). No version ranges in dependency lists.
  • Transitive dependencies pinned via [tool.uv].constraint-dependencies in the SDK and API manifests. The constraint set mirrors the versions locked in the corresponding uv.lock. A future uv lock preserves these versions instead of silently picking up newer releases, and the resolver fails when a constraint becomes infeasible, signaling that a deliberate bump is needed.
  • Lock files committed. CI installs strictly from the lock.
  • uv itself pinned in the setup-python-uv composite action.
The MCP Server declares a small constraint set of its own, covering transitive pins that fastmcp does not raise on its own. Its lock file remains the source of truth for everything else.

​
JavaScript/TypeScript (pnpm)

The UI uses pnpm with supply-chain controls configured in ui/pnpm-workspace.yaml.
  • Minimum release age (minimumReleaseAge: 1440): packages must publish at least 24 hours before install. This reduces exposure during the window when a compromised release has not yet been detected and yanked.
  • Lifecycle script allow-list (strictDepBuilds: true + allowBuilds): only explicitly approved packages may run install or postinstall scripts (currently sharp, esbuild, @sentry/cli, unrs-resolver, msw). Any unlisted package with lifecycle scripts fails the install.
  • Trust policy (trustPolicy: no-downgrade): the install fails when a package’s trust evidence drops, for example after a new publisher takes over.
  • Block exotic subdeps (blockExoticSubdeps: true): transitive dependencies cannot ship as git URLs or tarballs. Every package in the tree resolves from the configured registry.
  • Transitive overrides in ui/package.json force specific versions for transitive packages (lodash, serialize-javascript, qs, rollup, minimatch, ajv, and others).
  • pnpm-lock.yaml committed and CI installs strictly from the lock.
  • pnpm itself pinned via the packageManager field in package.json with an integrity hash.

​
GitHub Actions

  • Every third-party action reference uses a commit SHA, with the version in a trailing comment.
  • Dependabot opens monthly PRs to bump pinned SHAs.

​
Container Base Images

  • Every Dockerfile references base images by digest (image@sha256:...).
  • Dependabot opens monthly PRs to bump digests.

​
Container Security

Container images get scanned twice: once in CI before they push to a registry, and continuously after publish by the registries themselves.

​
Pre-Publish (CI)

  • Trivy scans for OS-package and application-dependency vulnerabilities. Runs on every pull request and push that touches an image or its dependencies. Trivy uploads SARIF to the GitHub Security tab and posts a summary on the PR. Builds fail on any critical finding that is not explicitly accepted. Accepted findings live in .trivyignore.yaml, each carrying a reason and an expiry date, the same policy osv-scanner.toml follows. A local trivy image run does not apply these suppressions unless you pass --ignorefile .trivyignore.yaml: Trivy auto-loads only the classic .trivyignore format, never the YAML one.
  • Hadolint validates Dockerfile syntax and structure against secure-build best practices. Runs in pre-commit and alongside the image scans above.

​
Post-Publish (Registries)

  • Amazon ECR: ECR continuously scans published images for vulnerabilities. New advisories disclosed after publish surface on the image without requiring a rebuild.
  • Docker Hub: Docker Hub continuously scans the same images mirrored from ECR.
  • The security team reviews findings from both registries for triage and remediation.

​
Known Findings

A small number of findings remain in the published images and cannot be resolved by Prowler: the upstream project has released no fix, the package cannot be removed without breaking the image, or the finding comes from a vendored SBOM rather than from a package that is actually installed. Alternative base distributions have been evaluated and none currently satisfies both the vulnerability profile and the runtime requirements of every supported provider. Each suppression is recorded in .trivyignore.yaml with the reason it cannot be fixed, why it is not exploitable in Prowler’s runtime, and an expiry date that forces re-review. Nothing is suppressed without that rationale, and a build fails on any critical finding that is not listed there. To see the current set for any image, scan it directly. This reports everything, including the accepted findings above, because Trivy does not read .trivyignore.yaml unless it is named:
To see only what is not already accepted, point Trivy at the suppression file:

​
Secrets Detection

  • TruffleHog scans the codebase and git history on every push and pull request. Detects high-entropy strings, API keys, tokens, and credentials, and reports verified and unknown findings.
  • A pre-commit hook runs the same check locally and blocks secrets before they leave the developer machine.

​
Security Monitoring

  • GitHub Security tab: centralized view of findings from CodeQL, Trivy, zizmor, and any other SARIF-compatible tool.
  • PR comments: osv-scanner and Trivy post per-PR summaries so issues surface during review, not after merge.
  • Artifact retention: the build retains security scan reports for post-deployment analysis.

​
Contact

For questions about software security, see the Support page. To report a vulnerability, follow the responsible disclosure process.