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.