Issue assistant

Only the latest release gets fixes. Repositories pin the commit hash of a release, and Renovate or Dependabot open the update pull request; a release that changes the templates says so in its notes and asks to run install again, and a change that breaks the settings is a major version. https://github.com/Dennis-Otto/issue-assistant/blob/main/SECURITY.md#supported-versions

GitHub Issues, with issue forms for bugs and feature requests: https://github.com/Dennis-Otto/issue-assistant/issues

No vulnerability was reported or resolved in the last 12 months; the repository has no security advisory. SECURITY.md promises credit in the advisory and the release notes to every reporter who doesn't prefer anonymity. https://github.com/Dennis-Otto/issue-assistant/blob/main/SECURITY.md#what-happens-next

SECURITY.md documents the process: private reporting through GitHub, acknowledgement within 7 days, a first assessment within 14 days, a fix of a confirmed vulnerability within 90 days at the latest, an update at least every 14 days when it takes longer, and disclosure in a GitHub security advisory and the release notes with credit for the reporter. https://github.com/Dennis-Otto/issue-assistant/blob/main/SECURITY.md#what-happens-next

CONTRIBUTING.md names the style guides that contributions must follow: PEP 8 in the format of Ruff with the Ruff rules of pyproject.toml and strict mypy for Python, ShellCheck for shell scripts, actionlint and zizmor for workflows, markdownlint for Markdown and .editorconfig for every text file, plus the rules of the action itself (standard library only, no vendor name outside the engine table). https://github.com/Dennis-Otto/issue-assistant/blob/main/CONTRIBUTING.md#coding-standards

scripts/check.sh runs ruff format --check, ruff check and mypy --strict, the Lint workflow actionlint, markdownlint, REUSE and the DCO check, and zizmor audits the workflows; all are required checks of every pull request. tests/test_templates.py enforces the rules of the templates and the vendor rule.

The project produces no native binaries: the action is a Python script that GitHub's runners run from source.

There is no compiled build: the action is a Python script that GitHub's runners run from source.

There is no build system that builds subdirectories: the action is a Python script that GitHub's runners run from source.

No building occurs: the action is the tagged commit of a Python script that runs from source.

A repository installs the action the common way of GitHub Actions, with uses: and a commit hash; install writes the four workflows, and deleting them uninstalls it. https://github.com/Dennis-Otto/issue-assistant/blob/main/README.md#set-up-a-repository

There is no POSIX installation step that writes to a chosen location: GitHub Actions (uses: with a commit hash) decides where the files go.

CONTRIBUTING.md shows how to set up everything to make and test changes: a virtual environment and pip install --require-hashes -r requirements-dev.txt, then bash scripts/check.sh runs every check of the CI. The dev container in .devcontainer/ sets it up in one step for VS Code and GitHub Codespaces, and git config core.hooksPath .githooks runs the checks before every push. https://github.com/Dennis-Otto/issue-assistant/blob/main/CONTRIBUTING.md#checks

The action needs only Python's standard library, gh and git at run time; the tools of development are listed in requirements-dev.in and pinned with hashes in requirements-dev.txt, and the fuzzing tools in requirements-fuzz.txt. https://github.com/Dennis-Otto/issue-assistant/blob/main/requirements-dev.txt

Renovate updates the dependencies, an update that fixes a vulnerability at once; OSV-Scanner checks every lock file on every pull request and every week and reports to code scanning, where the Findings workflow keeps every finding fixed or accepted with a reason; the dependency review blocks pull requests that bring in a dependency with a known vulnerability. https://github.com/Dennis-Otto/issue-assistant/blob/main/.github/workflows/osv-scanner.yml

The action uses only the standard library of the runner's Python; the tools of development come from pip, pinned with hashes, and Renovate updates them. No third-party code is copied into the repository.

Ruff's pyupgrade rules (UP) replace outdated Python constructs, mypy runs in strict mode, and the actions of the workflows stay current through Renovate.

The CI runs scripts/check.sh, the whole test suite with its coverage gate, on every push to main and on every pull request, and reports success or failure as required checks; the action-test workflow runs the action itself. https://github.com/Dennis-Otto/issue-assistant/blob/main/.github/workflows/ci.yml

All 6 bugs fixed in the last six months brought a regression test; findings of the property tests and the fuzzing become examples in test_tricky_text_is_cleaned_safely.

scripts/check.sh runs pytest under coverage.py, a FLOSS tool, and fails below 100 % of the lines and branches of issue_assistant.py (fail_under = 100 in pyproject.toml). https://github.com/Dennis-Otto/issue-assistant/blob/main/pyproject.toml

CONTRIBUTING.md has the written policy: new functionality comes with tests in the automated test suite, in the same pull request, and every fix with a test that fails without it; a pull request without the tests it needs is not merged. https://github.com/Dennis-Otto/issue-assistant/blob/main/CONTRIBUTING.md#tests

The instructions for change proposals in CONTRIBUTING.md require tests for new functionality, and the checklist of the pull request template asks for them. https://github.com/Dennis-Otto/issue-assistant/blob/main/CONTRIBUTING.md#tests

mypy runs in strict mode and Ruff with the rule sets E, F, I, B, UP and SIM; actionlint and zizmor treat every finding in the workflows as a failure.

The repository and its releases apply least privilege, fail-safe defaults, complete mediation, separation of privilege, least common mechanism, economy of mechanism, open design and psychological acceptability, as the assurance case of SECURITY.md shows; docs/security.md shows the secure design of the software: the AI only reads, a job without the AI writes, secrets stay in one environment, and untrusted text never reaches a shell. https://github.com/Dennis-Otto/issue-assistant/blob/main/docs/security.md

The action implements no security mechanism with cryptography of its own; it relies on GitHub's tokens and TLS.

The software implements no cryptographic algorithm of its own; TLS comes from the GitHub CLI and the engine's action, which verify certificates by default.

The token of the engine is a secret of the GitHub environment issue-assistant, separate from every file and setting, and is replaced with gh secret set without any change of code; the action stores no credentials.

Every connection goes over HTTPS: to GitHub through the GitHub CLI and to the engine through its action; the job of the engine runs on a runner whose egress firewall allows only named hosts.

The GitHub CLI and the engine's action use TLS 1.2 or later.

The GitHub CLI and the engine's action verify TLS certificates by default; the action never turns that off.

TLS certificates are verified in the handshake, before any HTTP header with a token is sent; TLS comes from the GitHub CLI and the engine's action, which verify certificates by default.

Releases are immutable from the next release on (the setting is on); GitHub signs an attestation that ties each tag to its commit, the tagged commits are signed by GitHub, and the release workflow signs the provenance of every file with Sigstore. SECURITY.md documents how users verify a release with gh release verify. https://github.com/Dennis-Otto/issue-assistant/blob/main/SECURITY.md#verify-a-release

Release tags never move (ruleset Release tags), and GitHub's signed release attestation ties every tag to its commit. From the next release on, the release workflow also signs every tag itself, without a key, with gitsign, and the release check verifies the signature and the identity of the workflow. https://github.com/Dennis-Otto/issue-assistant/blob/main/.github/sign-tag.sh

Every untrusted input is checked against an allowlist: the AI's answer against a JSON schema of its task with the labels and issue numbers that exist, links against the hosts of config.toml, inputs of the action through the environment only; anything that looks like a secret refuses the answer. https://github.com/Dennis-Otto/issue-assistant/blob/main/docs/security.md#trust-boundaries

The engine runs with --restricted and the tools Read, Grep and Glob alone, on GitHub's egress-firewall runner with an allowlist of hosts; every workflow starts without permissions, pins its actions by commit hash and runs under Harden-Runner; the text of the AI is cleaned so that no mention, image, HTML or foreign link can form, guarded by property tests and fuzzing.

SECURITY.md has the assurance case of the repository and its releases: the threat model, the trust boundaries, the secure design principles and how the OWASP Top 10 CI/CD security risks are countered, with CodeQL for the CWE Top 25. docs/security.md completes it for the action: what it protects, its trust boundaries, its threats with countermeasures and the tests that pin them, and the residual risks. https://github.com/Dennis-Otto/issue-assistant/blob/main/SECURITY.md#assurance-case https://github.com/Dennis-Otto/issue-assistant/blob/main/docs/security.md

CodeQL with its security-extended queries analyzes the Python and the workflows on every pull request and every push to main; zizmor audits the workflows for their known attack patterns.

The project has no code in a memory-unsafe language: Python, YAML and Markdown prompts.