triss-coworker

Permissions are assigned at the minimum necessary per activity: every workflow and job declares scoped permissions (contents: read everywhere; id-token: write only for the npm publish job): https://github.com/ayleen/triss-coworker/blob/main/.github/workflows/publish.yml

Trusted-collaborator inputs to the release pipeline (the pushed tag name and its tree) are sanitized and validated before use: publish-gate.js verify-versions and authorize-tag validate the tag against package versions and origin/main before anything runs, and the install.sh drift check compares file contents: https://github.com/ayleen/triss-coworker/blob/main/scripts/publish-gate.js

Every release asset is named with the release identifier — triss-coworker-<version>-standalone.ndjson.gz, triss-coworker-<version>-standalone.sha256 — and the release page groups them under the matching vX.Y.Z tag: https://github.com/ayleen/triss-coworker/releases

The secrets management policy covers storing, accessing, and rotating credentials — user secrets in env/0600 files, infrastructure secrets in GitHub Actions with OIDC-backed npm publication, signing key with only its public half committed, rotation triggers and procedure: https://github.com/ayleen/triss-coworker/blob/main/SECURITY.md#secrets-management-policy

Instructions for verifying integrity and authenticity of release assets — npm provenance attestations, the standalone bundle sha256 against the shipped checksum file: https://github.com/ayleen/triss-coworker/blob/main/docs/verifying-releases.md

Instructions for verifying the expected identity of the release author — importing the committed public key and running git verify-tag on the release tag: https://github.com/ayleen/triss-coworker/blob/main/docs/verifying-releases.md#release-author-tag-signature

Support scope and duration per release: the latest release line is the only supported line (bug and security fixes until the next release ships); no LTS during 0.x: https://github.com/ayleen/triss-coworker/blob/main/docs/support.md

Statement on when versions stop receiving security updates: a version stops receiving security updates the moment its successor is published; there is no overlap window: https://github.com/ayleen/triss-coworker/blob/main/docs/support.md#security-updates-and-end-of-life

GOVERNANCE.md defines the review-before-escalation policy: a contributor becomes a maintainer only after sustained reviewable work, demonstrated security judgment, and approval by existing maintainers; release access is least-privilege and revoked when no longer needed: https://github.com/ayleen/triss-coworker/blob/main/GOVERNANCE.md

The project ships no compiled software assets — the npm package is interpreted JavaScript source and the standalone bundle is the same modules archived; there is nothing compiled to attach a compiled-asset SBOM to.

Single-repository monorepo; the release comprises one codebase with one set of enforced security gates, so there are no subprojects that could lag behind the primary.

When and how tests run is documented — local commands (npm test, npm run check) in CONTRIBUTING.md and the CI matrix description (Node 22 and 24, what each job runs): https://github.com/ayleen/triss-coworker/blob/main/CONTRIBUTING.md#test-and-lint

The test policy requires that behavior changes add or update tests — documented in CONTRIBUTING (document the contract first, add focused failing coverage, run the full suite; do not weaken tests): https://github.com/ayleen/triss-coworker/blob/main/CONTRIBUTING.md#security-sensitive-changes

Threat modeling and attack surface analysis are documented in THREAT_MODEL.md — assets, trust boundaries, attacker capabilities against critical code paths (prompt injection, path escape, credential discovery, command execution), and the countered-weakness expectations per boundary: https://github.com/ayleen/triss-coworker/blob/main/THREAT_MODEL.md

The remediation threshold policy for SCA findings (vulnerabilities and licenses): Critical/High dependency findings block a release, Medium within 30 days, licenses must be MIT-compatible per THIRD_PARTY_NOTICES: https://github.com/ayleen/triss-coworker/blob/main/SECURITY.md#dependency-findings-sca--vulnerabilities-and-licenses

SCA violations are addressed prior to any release: dependency-review fails pull requests on vulnerable or license-violating changes, Dependabot opens weekly upgrades, and the tag-driven publish pipeline reruns the same review and test gates before publishing — no release ships with an open Critical/High finding: https://github.com/ayleen/triss-coworker/blob/main/SECURITY.md#dependency-findings-sca--vulnerabilities-and-licenses

Dependabot monitors npm and GitHub Actions dependencies weekly and opens update pull requests; CodeQL and gitleaks also run in CI: https://github.com/ayleen/triss-coworker/blob/main/.github/dependabot.yml [dependency_monitoring]

The SAST remediation threshold policy: CodeQL Critical/High block merge (enforced by the code-scanning branch rule), Medium triaged within 90 days, suppressions require a written non-exploitability justification: https://github.com/ayleen/triss-coworker/blob/main/SECURITY.md#code-findings-sast

Every change is automatically evaluated by CodeQL (javascript-typescript and actions suites) on pull requests and pushes, and pull requests introducing new High/Critical alerts are blocked by the repository ruleset — observed failing PR #99 until the findings were fixed in code: https://github.com/ayleen/triss-coworker/blob/main/.github/workflows/