presidio-hardened-angellist

Both halves of the criterion are satisfied: two version lines are actively maintained, and a documented upgrade path exists for the rest. https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SECURITY.md#supported-versions states support per line — 0.7.x (current, latest 0.7.1) and 0.6.x are supported; 0.5.x through 0.2.x are marked superseded with an explicit instruction to upgrade to 0.7.x, noting that 0.5.x in particular should move up for the SSRF and dependency-CVE fixes; 0.1.x is end-of-life because it wrapped the AngelList Startup/Funding Data API, which has since been shut down, so no successor interface exists for it.
The upgrade path itself is straightforward and documented rather than difficult. https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SEMVER.md defines the pre-1.0 semver profile: patch releases carry bug and security fixes with no API change and are safe to auto-upgrade; minor releases are additive only, so existing code keeps working, and deprecations are announced at least one minor before any change; only a major release may remove deprecated surface. It also defines precisely what counts as the public API (everything in presidio_angellist.all, the dataclass fields, the exception hierarchy, the angeltriage CLI contract, and the environment-variable contract), so an integrator can tell whether an upgrade can affect them. Integrators are advised to pin to the current minor and run the verification procedure at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SEMVER.md#verifying-an-installation on every upgrade.
Per-release detail is in https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CHANGELOG.md, hand-written in Keep a Changelog format. Data compatibility is addressed explicitly: the SQLite deal store is opened rather than rewritten by an upgrade, and https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SEMVER.md#schemawire-stability states plainly that the store ships no migration mechanism today and that any future schema change will be announced in the changelog together with its upgrade path.

https://github.com/presidio-v/presidio-hardened-angellist uses GitHub issues.

no vulnerabilities resolved in the last 12 months

The process is documented at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SECURITY.md#reporting-a-vulnerability and covers intake, timing, and outcome. Intake: reports are made privately, either as a GitHub Security Advisory through the repository's Security tab (preferred, with a direct link given) or by email to security@presidio-group.eu; the policy states explicitly that a suspected vulnerability must not be opened as a public issue. Reporters are asked for a description, reproduction steps, impact, and a suggested fix if they have one. Response commitments: acknowledgement within 5 business days, a patch targeted within 30 days of a confirmed vulnerability, and progress updates until the issue is either resolved or dismissed with a stated rationale. Resolution: fixes ship as patch releases on the latest supported minor line, with any minimum-safe dependency floors raised in the same release (https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SEMVER.md#security-response), the reporter is credited unless they request anonymity, and the project follows coordinated vulnerability disclosure. CONTRIBUTING.md points contributors at this same process so the private path is discoverable from the contribution instructions, not only from SECURITY.md.

The primary and only language is Python. The style guide is ruff's implementation of PEP 8 with an explicit project configuration, declared under [tool.ruff] in https://github.com/presidio-v/presidio-hardened-angellist/blob/main/pyproject.toml — line length 99, target version py310, and the rule sets E, F, W (pycodestyle/pyflakes), I (import sorting), N (PEP 8 naming), UP (pyupgrade), S (flake8-bandit security), B (bugbear), A (builtin shadowing), C4, SIM, and TCH. Compliance is required of contributions and stated as such at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CONTRIBUTING.md#style, which also records why each of the three project-wide rule exclusions exists and forbids blanket noqa suppressions of security findings. Formatting is not a matter of taste: ruff format is the single authority.

Enforced automatically by ruff, a FLOSS tool, in CI. The test job of https://github.com/presidio-v/presidio-hardened-angellist/blob/main/.github/workflows/ci.yml runs both ruff check . and ruff format --check . on every push and every pull request, across all four supported Python versions, and fails the build on any finding. There is no warning-only mode and no advisory pass — main is protected with required status checks, so a non-conforming change cannot merge. The same commands are documented in the CONTRIBUTING local-verification block so contributors can reproduce the gate before pushing.

No native binaries are generated. This is a pure-Python package built by hatchling through PEP 517; there is no compiler or linker invocation anywhere in the build, so CC, CFLAGS, CXX, CXXFLAGS, and LDFLAGS have nothing to be honoured against. The package contains no C extension, no ctypes, and no cffi.

There are no compiled artifacts and therefore no debugging information to preserve or strip. The wheel contains Python source only; nothing resembling install -s occurs, because installation is performed by pip rather than by a make-style install step.

There is no recursive build. The entire build is a single PEP 517 invocation (python -m build) with hatchling as the backend — no make, no subdirectory builds, and so no possibility of cross-dependencies between recursively-built subdirectories.

No compilation occurs: this is a pure-Python project, and the criterion's own N/A clause for scripting languages whose source is used directly rather than compiled applies. The wheel and sdist produced by python -m build package the same .py source files that are executed at runtime; there is no compiler, no linker, and no generated binary or generated source whose bit-for-bit reproducibility could differ between builds. Separately, and not claimed here: the project pins its GitHub Actions to commit SHAs but declares runtime dependencies as version floors rather than an exact-pinned lockfile, so the resolved dependency set is not reproducible across time. That is a dependency-pinning gap rather than a build-determinism one, and it is recorded against external_dependencies rather than dressed up here.

Standard PyPI install and uninstall, with no build step and no compiler required. Install: pip install presidio-hardened-angellist for the deterministic core, or pip install 'presidio-hardened-angellist[llm]' to add the Claude-backed extraction and memo. Uninstall: pip uninstall presidio-hardened-angellist. Both commands are the ordinary convention for the language, work identically under pip and uv, and are documented at https://github.com/presidio-v/presidio-hardened-angellist#installation. The package declares a single console entry point (angeltriage) which pip installs and removes along with it, leaving nothing behind outside the operator's own data directory.

Installation is performed by a language package manager (pip or uv) from PyPI, which manages its own target paths and respects its own environment (virtualenv, --target, --prefix). There is no POSIX-style install step, so DESTDIR does not apply — the criterion's "no standard convention" case.

One documented path installs the package, the tests, and the full test environment: pip install -e ".[dev]", which pulls pytest, pytest-cov, ruff, responses, and pip-audit alongside the package in editable mode. The complete block, including virtualenv creation and the lint-plus-test verification command, is at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CONTRIBUTING.md#local-verification, and the README repeats the uv equivalent (uv venv && uv pip install -e ".[dev,llm]"). Both are commonly-used conventions for Python. One caveat is documented rather than hidden: the Atheris fuzz extra is Linux-only, because Atheris publishes no macOS wheel and none for Python 3.10, so fuzzing runs in CI rather than locally on a developer Mac.

Dependencies are declared machine-readably in https://github.com/presidio-v/presidio-hardened-angellist/blob/main/pyproject.toml under [project].dependencies and [project.optional-dependencies]: three runtime dependencies (requests, urllib3, idna) plus separate llm, dev, and fuzz extras. A CycloneDX SBOM is additionally generated in CI on every push and attached to each GitHub Release as sbom.cdx.json, giving a full transitive component list in a standard machine-readable format. Stated precisely: the manifest uses version floors, not an exact-pinned lockfile — there is no uv.lock in the repository, so the resolved graph can vary across time. Currency and vulnerability status are handled by Dependabot on both pip and GitHub Actions and by pip-audit gating every build.

Three independent mechanisms, all continuous rather than periodic. pip-audit runs in the test job on every push and pull request and fails the build on any dependency with a known vulnerability, so an exploitable dependency cannot merge. Dependabot is configured for both pip and GitHub Actions with weekly checks (https://github.com/presidio-v/presidio-hardened-angellist/blob/main/.github/dependabot.yml), and Dependabot vulnerability alerts plus automated security-fix pull requests are enabled on the repository. OpenSSF Scorecard runs weekly and on push to main and independently scores dependency currency. There are no vendored or convenience copies to check separately — every reused component is an ordinary PyPI package installed by the package manager. Current state: pip-audit reports no known vulnerabilities and there are 0 open code-scanning alerts.

Both halves of the criterion hold. The project leans heavily on the Python standard library — email, csv, html.parser, sqlite3, ssl, smtplib, imaplib, json, ipaddress, logging — so most reused functionality is the standard component provided by the language and updates with the interpreter. The three non-stdlib runtime dependencies are ordinary PyPI packages resolved by pip with no vendoring, no bundled copies, and no forks, so updating one is a version-floor change in pyproject.toml. This is exercised routinely rather than theoretically: the v0.6.0 release raised urllib3 and idna floors to close upstream CVEs, and merged PRs #21 through #34 are dependency and Action updates.

Dependencies are kept current by Dependabot on both pip and GitHub Actions, with floors raised above known CVEs. The codebase targets Python 3.10+ and ruff's UP (pyupgrade) rule set runs in CI, which actively flags deprecated and superseded Python idioms and fails the build on them — so drift onto obsolete APIs is caught mechanically, not by inspection. Concretely, the code uses timezone-aware datetime handling, ipaddress for address classification, and ssl.create_default_context() rather than deprecated predecessors. The project's own public API surface is documented at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SEMVER.md with a stated deprecation policy: any deprecation is announced at least one minor release ahead, and removal may only occur in a major release.

The full suite runs on every check-in to the shared repository — on every push to main and on every pull request targeting it — via https://github.com/presidio-v/presidio-hardened-angellist/blob/main/.github/workflows/ci.yml. It reports success or failure per job in the GitHub Actions UI and as commit status checks; the matrix legs test (3.10) through test (3.13) are required status checks on main, so a failing report blocks the merge rather than merely being recorded. 268 tests across 16 modules, on CPython 3.10, 3.11, 3.12, and 3.13. Coverage figures are printed in the job log and coverage.xml is retained as a build artifact.

Above 50% for the period, and verifiable from the merge history. Worked example: PR #20 (v0.7.1) fixed the local-LLM backend returning empty content for reasoning models — +95 lines in src/presidio_angellist/llm.py shipped with +71 lines in tests/test_llm.py in the same pull request. Every functional fix merged in the last six months (PRs #17, #18, #19, #20) carried its tests in the same change; the remaining merges in that window (PRs #21–#34) are dependency and Action-pinning updates with no behavioural surface to regress. The policy requiring this is written at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CONTRIBUTING.md#tests, and the coverage gate makes an untested fix hard to land regardless.

Measured statement coverage is 95.3%, well above the 80% bar, using coverage.py via pytest-cov — both FLOSS. The gate is enforced in CI rather than merely measured: the test job of https://github.com/presidio-v/presidio-hardened-angellist/blob/main/.github/workflows/ci.yml requires statement coverage of at least 90% and, separately, branch coverage of at least 80% (currently 86.0%), read from coverage.json. The two metrics are checked independently on purpose, because --cov-fail-under blends them into a single figure and would let branch coverage sag behind a high statement number. Both floors are enforced on all four supported Python versions.

A formal written policy at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CONTRIBUTING.md#tests states in mandatory terms: "any change that adds or modifies functionality must ship with tests in the same pull request," and bug fixes must include a regression test that fails before the fix and passes after it. The policy is backed by two enforcement mechanisms rather than good intentions — it is an explicit item on the reviewer's checklist in the Code review section, and the CI coverage floors (statement 90%, branch 80%) fail the build if new code arrives untested. CONTRIBUTING.md is the document contributors are pointed to, so the policy sits in the change-proposal instructions themselves.

The policy is stated in the contribution instructions themselves: https://github.com/presidio-v/presidio-hardened-angellist/blob/main/CONTRIBUTING.md#tests

Enabled ruff rule sets, well beyond the E4/E7/E9/F default: E, F, W (pycodestyle/pyflakes), I (import sorting), N (naming), UP (pyupgrade), S (flake8-bandit security rules), B (bugbear), A (builtin shadowing), C4 (comprehensions), SIM (simplification), TCH (type-checking imports). Documented exclusions: S101 (bare assert is correct in tests), S603/S607 (inherited from the shared Presidio ruff profile; this package invokes no subprocess, so neither rule has anything to suppress), and N802 under fuzz/ because Atheris dispatches on the exact function name TestOneInput.

Argued per principle, grounded in real controls, at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/ASSURANCE.md#3-secure-design-principles-applied. Fail-safe defaults: every network capability is off until the operator enables it (enrichment needs --enrich, LLM steps need a configured backend, IMAP and SMTP need environment credentials), and each security control raises rather than degrading — a non-HTTPS scheme, a non-public host, an invalid weights file, or plaintext IMAP stops the operation. Complete mediation: the scheme check, HTTPS upgrade, SSRF guard, and rate limiter live inside HardenedSession.request, and log redaction is a logging.Filter attached to the package logger at import, so neither can be bypassed or forgotten by a future caller — a new _log.info anywhere in the package is covered the moment it is written. Least privilege: the project holds no long-lived secret of its own, opens the IMAP mailbox read-only, publishes via short-lived OIDC credentials rather than a stored token, and declares read-only top-level tokens in every workflow with only the single job needing security-events: write elevating. Defence in depth: transport hardening, destination validation, log hygiene, input hygiene, and supply-chain controls are independent layers, and because the scoring rubric is deterministic and model-free, a successful prompt injection cannot change the score, only the advisory prose. Economy of mechanism: no cryptography is implemented, stdlib parsers are used throughout, and the runtime dependency set is three packages.

Met as of v0.7.2. Three independent signatures cover each release, and the private key for none of them lives on a distribution site. (1) The release git tag is SSH-signed with the organisation's release key; GitHub reports it Verified (the API's verification.verified is true for v0.7.2) and it verifies locally with git -c gpg.ssh.allowedSignersFile=allowed_signers verify-tag v0.7.2. The key's private half is held only in the organisation's password manager and is never on PyPI, GitHub, or a build runner; only the public half is committed, as https://github.com/presidio-v/presidio-hardened-angellist/blob/main/allowed_signers. (2) A Sigstore-backed in-toto build-provenance attestation is produced over the artifacts by the tag-triggered workflow and attached to the GitHub Release as provenance.intoto.jsonl, alongside a CycloneDX SBOM; it verifies with gh attestation verify <artefact> --repo presidio-v/presidio-hardened-angellist. (3) The PyPI artifacts carry PEP 740 attestations issued through Trusted Publishing (OIDC), retrievable from PyPI's integrity API; signing uses ambient short-lived credentials, so again there is no long-lived private key anywhere, least of all on the index. The documented verification process for all three is at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SECURITY.md#verifying-releases-and-obtaining-public-signing-keys. Note for completeness: tags up to and including v0.7.1 predate tag signing and are unsigned, since a published tag cannot be re-signed; signed tags begin at v0.7.2.

Met as of v0.7.2. The release tag is SSH-signed with the organisation's release key and verifiable both ways: GitHub reports it as Verified (verification.verified is true via gh api repos/presidio-v/presidio-hardened-angellist/git/tags/<sha>), and it verifies locally against the public key committed in the repository with git -c gpg.ssh.allowedSignersFile=allowed_signers verify-tag v0.7.2, which reports a good signature for ED25519 key SHA256:MLin275d/xTVoZqBhyHETA8iZ7xfX29es/L2PdedxPw. The verification procedure is documented at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/SECURITY.md#verifying-releases-and-obtaining-public-signing-keys, as required by signed_releases. Stated plainly: the three earlier tags (v0.6.0, v0.7.0, v0.7.1) predate the adoption of tag signing and remain unsigned, because a published tag cannot be retroactively signed. Every tag from v0.7.2 onward is signed.

Untrusted input is checked at the boundary before use, with the boundaries enumerated at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/ARCHITECTURE.md#trust-boundaries. Operator configuration is allowlisted and fails closed: a --rubric file is rejected outright if it contains any top-level key outside the recognised set, with the error naming the valid keys, and a --weights file is rejected on an unknown rubric dimension, a non-numeric, negative, or boolean value, a non-object document, or an all-zero weight set, raising WeightsConfigError rather than silently substituting a default — a typo in a weights file must not quietly change how a deal scores. Deal-workflow status values are likewise restricted to a fixed tuple. For free-form untrusted content, where an allowlist of values is not meaningful, the restriction enforced is structural: forwarded emails and CSVs are parsed only by the stdlib email and csv modules, HTML is reduced to text by an html.parser subclass that drops script, style, head, and title rather than interpreting them, and the extracted text can only populate typed dataclass fields — it never reaches a shell, a SQL statement, the filesystem, or an eval. On the egress side the company URL extracted from that untrusted email is validated before any fetch: the scheme must be HTTPS (http is upgraded, anything else refused) and assert_public_host resolves the host and rejects loopback, private, link-local including 169.254.169.254, reserved, multicast, and unspecified addresses, checking every resolved address and unwrapping IPv4-mapped IPv6. The parsing path is additionally fuzzed with Atheris in CI.

Hardening mechanisms in place, all verifiable in the repository. At runtime: TLS 1.2 floor with mandatory certificate and hostname verification and an ephemeral-EC-only cipher list on all egress; HTTP upgraded to HTTPS and other schemes refused; an SSRF guard on every attacker-influenced fetch; sink-level secret redaction via a logging filter installed at import, so credentials cannot reach a log even from a call site that forgets to redact; credentials read from environment variables only and never accepted as command-line arguments, which would expose them in ps output and shell history; plaintext IMAP refused unless explicitly overridden; the IMAP mailbox opened read-only; fully parameterized SQL; and bounded retries, per-host rate limiting, and explicit timeouts to limit resource exhaustion. In the supply chain: every GitHub Action pinned to a commit SHA; read-only top-level workflow tokens with elevation only in the one job that needs it; persist-credentials: false on checkouts; protected main with required status checks and admin enforcement; OIDC Trusted Publishing with no stored PyPI token, behind a required-reviewer deployment environment; and SBOM plus build-provenance attestation on releases. Not applicable here: there is no container image, so no base-image digest pinning, and Python provides memory safety without needing compiler hardening flags.

https://github.com/presidio-v/presidio-hardened-angellist/blob/main/ASSURANCE.md is the assurance case and contains all four required elements. (1) Threat model, section 1: names the two assets — the analyst's machine and network position, since the tool ingests email from strangers and on request fetches URLs those strangers chose, and the analyst's credentials plus commercially sensitive deal data — then maps twelve concrete threats each to the control that counters it, and states five out-of-scope items explicitly rather than leaving them implied (prompt injection is mitigated but not solved, DNS rebinding, endpoint and account security, the operator-configured LLM endpoint, and correctness of the investment judgement). (2) Trust boundaries, section 2: eight boundaries, each named, classified as input-validation or egress, and given its control, cross-referenced to the canonical table in ARCHITECTURE.md#trust-boundaries. (3) Secure design principles, section 3: fail-safe defaults, complete mediation, least privilege, defence in depth, and economy of mechanism, each argued against specific code rather than asserted. (4) Common implementation weaknesses, section 4: a table of ten weakness classes — CWE-20/74 including prompt injection, CWE-89, the CWE-119 memory-safety family, CWE-327/916, CWE-798/532, CWE-319/295/918, CWE-502, CWE-400, CWE-1104, CWE-1357 — each mapped to a control and to the tool that checks it, followed by the named SAST and posture tooling actually run. The document also records plainly that no independent third-party security review has been commissioned, and does not claim one.

CodeQL's security-extended suite specifically targets common vulnerability classes (injection, path traversal, SSRF, unsafe deserialization, weak crypto), and Bandit adds a Python-specific pass over the same classes. The weakness classes this project is exposed to are enumerated and each mapped to both a control and the tool that checks it at https://github.com/presidio-v/presidio-hardened-angellist/blob/main/ASSURANCE.md#4-common-implementation-weaknesses-countered. pip-audit covers the dependency-CVE side and fails the build on any known-vulnerable package. All are currently clean, with 0 open code-scanning alerts.

The test suite is assertion-based (pytest, 268 tests) and nothing runs under -O, so assertions are checked. The fuzz job likewise invokes python without -O and does not set PYTHONOPTIMIZE, so runtime assertions stay enabled during fuzzing.