Skip to main content
Palyra employs a multi-layered security pipeline integrated into its CI/CD workflows to ensure the integrity of the software supply chain, protect against secret leakage, and validate the security posture of both Rust and Node.js dependencies. These gates are primarily orchestrated via GitHub Actions and custom validation scripts.

​
Automated Security Workflows

The primary security enforcement occurs in the security.yml workflow, which runs on every pull request and push to the main branch. This workflow aggregates several specialized security tools to provide comprehensive coverage.

​
Workflow Data Flow

The following diagram illustrates how security artifacts are generated and validated during the CI process. Security Artifact Pipeline Sources: .github/workflows/security.yml#1-156, .github/workflows/codeql.yml#1-48

​
Dependency Scanning and Governance

​
Rust Dependency Auditing

Palyra uses three distinct tools to audit Rust dependencies:
  1. cargo audit: Checks Cargo.lock against the Advisory Database for crates with known vulnerabilities .github/workflows/security.yml#95-96.
  2. cargo deny: Enforces policy on dependencies, including license compliance (allowing only approved licenses like Apache-2.0, MIT, and PCSL v1.1) and banning specific crates or wildcard versions [deny.toml#1-111, [.github/workflows/security.yml:98-99]]().
  3. OSV Scanner: Uses Google’s Open Source Vulnerabilities database to provide an additional layer of vulnerability detection .github/workflows/security.yml#101-104.

​
Node.js Audit with Dev-Allowlist

For the web and desktop UI, Palyra implements a strict npm audit policy that distinguishes between production and development dependencies.
  • Runtime Audit: Any high-severity vulnerability in a production dependency (non-dev) triggers an immediate failure .github/workflows/security.yml#30-31.
  • Dev-Allowlist: Vulnerabilities in dev-dependencies (e.g., build tools, linters) can be temporarily allowlisted in npm-audit-dev-allowlist.json with a mandatory expiration date and owner [npm-audit-dev-allowlist.json#1-6, [scripts/validate-npm-audit-dev-allowlist.mjs:178-196]]().
  • Validation: The validate-npm-audit-dev-allowlist.mjs script ensures that no unallowlisted vulnerabilities exist and that no allowlist entries have expired scripts/validate-npm-audit-dev-allowlist.mjs#220-248.

​
Downstream Patch Governance

In rare cases where an upstream vulnerability cannot be immediately resolved, Palyra allows narrowly-scoped downstream patches. A current example is the glib patch for the desktop Linux runtime SECURITY.md#51-66. This is governed by:
  • Patch Verification: scripts/check-desktop-glib-patch.sh ensures the patch is applied correctly during build .github/workflows/security.yml#70-71.
  • Documentation: Mandatory documentation in docs/security/advisories/ explaining the exit plan back to upstream SECURITY.md#62-65.

​
Secret Scanning and Static Analysis

​
Gitleaks

The repository uses gitleaks to detect hardcoded secrets, such as API keys, tokens, or certificates. It is configured via .gitleaks.toml and runs as a SARIF-reporting gate in CI .github/workflows/security.yml#120-123.

​
CodeQL

GitHub CodeQL is configured to perform semantic analysis on the codebase for three languages: actions, javascript-typescript, and rust. It runs on a weekly schedule and on every PR to detect common vulnerability patterns like injection or memory safety issues .github/workflows/codeql.yml#19-48.

​
High-Risk Pattern Checks

A custom script, scripts/check-high-risk-patterns.sh, scans the codebase for patterns that may bypass security controls, such as:

​
Artifact Hygiene and SBOM

​
Runtime Artifact Hygiene

The scripts/check-runtime-artifacts.sh script ensures that no sensitive files (like local configuration, databases, or temporary keys) are accidentally included in the repository or build artifacts [.github/workflows/security.yml#125-126, [.github/workflows/ci.yml:185-186]]().

​
SBOM Generation

Palyra generates a Software Bill of Materials (SBOM) in CycloneDX JSON format using cargo cyclonedx. This provides a machine-readable inventory of all components, including their versions and licenses, facilitating downstream compliance and vulnerability tracking .github/workflows/security.yml#131-133.

​
Build Attestations

During the release process, Palyra generates build attestations. These are signed statements that link the final release artifacts (like the Desktop Portable Bundle) back to the specific GitHub Actions workflow and source commit that produced them [.github/workflows/release.yml#21-22, [.github/workflows/security.yml:147-148]]().

​
Security Policy and Reporting

The SECURITY.md file defines the project’s vulnerability disclosure policy. It mandates:
  • Private Reporting: Vulnerabilities should be reported via GitHub’s private reporting feature or emailed to info@marektomas.com SECURITY.md#18-32.
  • Supported Versions: Security fixes are prioritized for the main branch and the latest stable release SECURITY.md#8-14.
  • Pinned Actions: All GitHub Actions used in the repository must be pinned to a specific SHA to prevent supply chain attacks via compromised action tags [SECURITY.md#72-72, [.github/workflows/ci.yml:179-180]]().
Sources: SECURITY.md#1-75, .github/workflows/security.yml#1-156, deny.toml#1-111, scripts/validate-npm-audit-dev-allowlist.mjs#1-248