security-gates job in the GitHub Actions workflow.
Supply Chain Scanning Architecture
The security pipeline combines industry-standard scanners with custom governance scripts to validate the repository state before any release or PR merge.Dependency Auditing and Governance
Palyra manages vulnerabilities through three distinct scanners:npm audit, cargo audit, and osv-scanner.
1. Node.js (npm) Audit with Dev Allowlist
The system runs a dual-audit strategy for the Web Console and Desktop UI. It distinguishes between production (runtime) vulnerabilities and development-only vulnerabilities to prevent blocking CI on non-exploitable build-tool issues while maintaining strict zero-vulnerability requirements for runtime code.- Runtime Audit: Executes
npm audit --omit=devto ensure zero high-severity vulnerabilities in the shipped bundle .github/workflows/security.yml#30-31. - Dev Allowlist Validation: A custom script
scripts/validate-npm-audit-dev-allowlist.mjsprocesses the full audit report againstnpm-audit-dev-allowlist.json.github/workflows/security.yml#56-64. This ensures that any “allowed” dev-only vulnerabilities have an explicit owner, reason, and expiration date .scripts/validate-npm-audit-dev-allowlist.test.mjs#77-87.
2. Rust (Cargo) Audit and Deny
The Rust workspace is protected bycargo-audit and cargo-deny.
- cargo audit: Checks
Cargo.lockagainst the Advisory Database for security vulnerabilities .github/workflows/security.yml#95-96. - cargo deny: Enforces license compliance, detects duplicate dependencies, and validates the dependency graph against security advisories .github/workflows/security.yml#98-99.
3. OSV Scanner
Palyra uses the Google OSV Scanner to provide a cross-ecosystem view of vulnerabilities, scanning theCargo.lock file against the Open Source Vulnerability database .github/workflows/security.yml#101-104.
Downstream Patch Governance (glib)
In cases where an upstream fix is unavailable due to transitive constraints (e.g., Tauri’s dependency on older GTK/glib versions), Palyra employs a “Downstream Patch” model.- Mitigation: The
glibcrate is vendored and patched atapps/desktop/src-tauri/third_party/glib-0.18.5-patchedapps/desktop/src-tauri/docs/security/advisories/GHSA-wrw7-89jp-8q8g.md#27-29. - Enforcement: The script
scripts/check-desktop-glib-patch.shvalidates the SHA-256 checksum of the patched file (src/variant_iter.rs) to ensure the mitigation remains intact and is not accidentally overwritten during dependency updates .github/workflows/security.yml#70-71, apps/desktop/src-tauri/docs/security/advisories/GHSA-wrw7-89jp-8q8g.md#52-53.
Secret Detection and Pattern Scanning
Palyra implements aggressive detection for sensitive data and high-risk coding patterns.Gitleaks Secret Detection
The pipeline usesgitleaks to scan the entire repository history for secrets, API keys, and certificates .github/workflows/security.yml#120-124. It uses a project-specific configuration in .gitleaks.toml to minimize false positives while ensuring no real credentials reach the main branch.
High-Risk Pattern Scan
A custom scriptscripts/check-high-risk-patterns.sh performs static analysis via grep/regex to find dangerous code patterns that standard linters might miss .github/workflows/security.yml#128-129. This includes:
- Insecure usage of
unsafein Rust. - Hardcoded debug flags.
- Bypasses of the
palyra-policyengine.
Supply Chain Integrity (SBOM & SLSA)
To provide transparency and verify the provenance of release artifacts, Palyra generates standardized security metadata.SBOM Generation
Palyra usescargo-cyclonedx to generate a Software Bill of Materials (SBOM) in JSON format .github/workflows/security.yml#131-132. This document lists all components, versions, and licenses included in the Rust binaries. The SBOM files are collected and uploaded as security artifacts for every successful CI run .github/workflows/security.yml#134-145.
SLSA Provenance and Attestations
During the release process, Palyra generates build attestations to satisfy SLSA (Supply-chain Levels for Software Artifacts) requirements.- Build Attestations: The release workflow uses GitHub’s attestation service to sign the build provenance .github/workflows/release.yml#22.
- Checksum Manifests: SHA-256 manifests are generated for all portable desktop and headless release bundles .github/workflows/release.yml#87.
| Artifact Type | Tooling | Output Format |
|---|---|---|
| Rust SBOM | cargo-cyclonedx | sbom.json |
| Secret Scan | gitleaks | gitleaks-results.sarif |
| Vulnerability Report | osv-scanner | osv-results.json |
| Audit Summary | validate-npm-audit-dev-allowlist.mjs | npm-audit-dev-summary.json |
Security Policy and Reporting
The project maintains a strictSECURITY.md policy. Security fixes are prioritized for the main branch and the latest release SECURITY.md#12-14.
- Reporting: Vulnerabilities should be reported via GitHub Private Vulnerability Reporting SECURITY.md#20-24.
- Pinned Actions: CI enforces that all GitHub Actions are pinned to specific SHA-256 hashes to prevent tag-spoofing attacks .github/workflows/ci.yml#179-180, SECURITY.md#72.