summit

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The git repository contains full interim history between releases - every fix and feature lands as individual commits that are reviewed via CI before tagging. History with interim versions between v0.1.0, v0.2.0, v0.3.0 and v0.4.0: https://github.com/pennacle-security/summit/commits/main

Repository on GitHub, which uses git. git is distributed.

Every user-facing release carries a unique version identifier (v0.1.0, v0.2.0, v0.3.0, v0.4.0), declared in pyproject.toml and summit/init.py and compiled into the CLI banner. Releases: https://github.com/pennacle-security/summit/releases

Each release is identified with an annotated git tag: v0.1.0, v0.2.0, v0.3.0, v0.4.0. https://github.com/pennacle-security/summit/tags

Every release ships human-readable release notes - a summary of major changes, what is new, and upgrade impact - never a raw git log: https://github.com/pennacle-security/summit/releases . A structured changelog is also maintained in the repository: https://github.com/pennacle-security/summit/blob/main/CHANGELOG.md

N/A - summit has had no publicly known run-time vulnerabilities with CVE assignments, so there is nothing to list in release notes. (Users also update the tool themselves via git pull / pip install, so upgrade practicality is not a concern.)

GitHub provides defect reportingBug reports are submitted through GitHub Issues with structured templates (including a detection-quality field for false positives / false negatives): https://github.com/pennacle-security/summit/issues/new/choose - the process is documented in the contributing guide: https://github.com/pennacle-security/.github/blob/main/CONTRIBUTING.md mechanisms by default (via issues). [osps_do_02_01]

GitHub Issues is used as the issue tracker; every report and its resolution status is visible and searchable at https://github.com/pennacle-security/summit/issues

Yes - every bug report submitted to date has been acknowledged by a maintainer. The project is young (first release this month), so the report volume is small and response is fast. Public archive of reports and responses: https://github.com/pennacle-security/summit/issues?q=is%3Aissue

Yes - enhancement requests and roadmap proposals are triaged through the issue templates and the Ideas discussion (https://github.com/pennacle-security/summit/discussions/categories/ideas); every submission to date has received a maintainer response. Public archive: https://github.com/pennacle-security/summit/issues?q=is%3Aissue+label%3Aenhancement

GitHub Issues provides the public, searchable archive of all reports and responses; every thread is URL-addressable and open to new participants: https://github.com/pennacle-security/summit/issues

The vulnerability reporting process is published at https://github.com/pennacle-security/.github/blob/main/SECURITY.md - it instructs reporters to use private disclosure, lists what to include (affected repo, version/commit, reproduction, impact) and the response timeline (acknowledgment within 72 hours, fix or mitigation plan within 14 days).

Private vulnerability reporting is enabled via GitHub's Security Advisories flow: https://github.com/pennacle-security/summit/security/advisories/new - reports and discussion there are visible only to the reporter and maintainers. The process is documented in the security policy: https://github.com/pennacle-security/.github/blob/main/SECURITY.md

No vulnerability reports have been received in the last 6 months. The published policy commits to acknowledging any report within 72 hours and providing a fix or mitigation plan within 14 days - well inside the 14-day requirement: https://github.com/pennacle-security/.github/blob/main/SECURITY.md

Summit is pure Python and installs/builds from source with the standard toolchain: pip install -e . reads pyproject.toml (setuptools build backend, entry point summit = summit.cli:main) and rebuilds everything - no compilation step required. The build definition: https://github.com/pennacle-security/summit/blob/main/pyproject.toml - and CI proves it works on every push (pip install -e . in https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml).

The build uses only the most common Python tools: setuptools as the build backend with pip as the installer - the standard mechanism for Python projects. No custom build scripts, no exotic tooling.

The entire build chain is FLOSS: Python (PSF license), setuptools (MIT), pip (MIT). There are no proprietary tools anywhere in the build, test or release process.

The automated test suite (45 unit and integration tests) is public FLOSS in the repository: https://github.com/pennacle-security/summit/tree/main/tests - how to run it is documented in the contributing guide (https://github.com/pennacle-security/.github/blob/main/CONTRIBUTING.md) and executed in CI on every push: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml - beyond pytest, CI also runs a demo-scan smoke test and an evidence runner that re-verifies every README claim live.

The suite is invoked the standard way for Python: pytest -q from the repository root. The configuration lives in pyproject.toml and the invocation is documented in CONTRIBUTING.md and executed verbatim in CI: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml

The suite covers most functionality: HTTP model parsing, the spider, every passive check family (headers, cookies, error leaks, CORS, WAF fingerprints, CAPTCHA, takeover), every active check module (SQLi, XSS, WAF bypass, host header, CORS reflection, redirect, traversal), the rate limiter (with an injected clock), the prioritizer, the toolkit (JWT/base64/URL/hex), version comparison, plus live-server integration tests for retries and header handling. The CI additionally exercises the full pipeline end-to-end via the demo-scan smoke test and the evidence runner. Known gap, stated honestly: branch-level coverage is not yet tracked with a coverage tool - that is on the roadmap.

Continuous integration runs on every push and pull request via GitHub Actions: pytest, a demo-scan smoke test (seeded detections must fire, the healthy control link must stay unreported) and the evidence runner (every README claim re-verified live). Four workflows in total: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml

The policy is documented in the contributing guide: every new check or feature must add at least one test, and new network-touching checks must include a positive and a negative test against the local demo target: https://github.com/pennacle-security/.github/blob/main/CONTRIBUTING.md - the PR template also requires a "How tested" checklist (https://github.com/pennacle-security/summit/blob/main/PULL_REQUEST_TEMPLATE.md).

The most recent major changes followed the policy - each shipped with its tests in the same change:

• v0.4.0: three new check families (takeover fingerprints, host header injection, CORS reflection) each landed with tests in https://github.com/pennacle-security/summit/blob/main/tests/test_new_checks.py (live mini-server integration tests included)
• v0.3.0: WAF/CAPTCHA/rate-limiter/prioritizer/toolkit landed with https://github.com/pennacle-security/summit/blob/main/tests/test_waf.py
• v0.2.0: linkcheck landed with https://github.com/pennacle-security/summit/blob/main/tests/test_linkcheck.py

The test policy is documented in the instructions for change proposals: the PR template requires a "How tested" checklist (pytest passes locally, new checks registered, verified against the demo target): https://github.com/pennacle-security/summit/blob/main/PULL_REQUEST_TEMPLATE.md - and CONTRIBUTING.md states the "add at least one test" requirement: https://github.com/pennacle-security/.github/blob/main/CONTRIBUTING.md

Python is interpreted, so instead of compiler flags the project uses ruff (FLOSS, MIT) as the linter, configured in pyproject.toml with the warnings set (pycodestyle errors/warnings + pyflakes: E, F, W). The lint gate runs in CI on every push before the test suite: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml - configuration: https://github.com/pennacle-security/summit/blob/main/pyproject.toml

All warnings are fixed: ruff check summit tests reports zero findings ("All checks passed!"), enforced by the CI lint gate on every push. The lint introduction commit also cleaned the findings it surfaced (unused imports, empty f-strings, over-long lines refactored): https://github.com/pennacle-security/summit/commits/main

The lint gate is blocking, not advisory: a warning fails CI and the PR cannot merge (the main branch requires the tests check). The ruleset covers pycodestyle errors and warnings plus all pyflakes checks; going stricter (full ruff check default ruleset including opinionated lints) is planned as the codebase matures.

The primary maintainers (Pennacle Security) are offensive-security practitioners, and the design decisions are documented in the codebase itself, not just claimed: the SSRF guard in the link checker (private/link-local/metadata ranges are never fetched), safe probe hosts that cannot resolve (.example), the two-stage canary design that prevents payload spraying, and the confidence-label contract that prevents overstating findings. See the anti-false-positive design section and examples/evidence.py which verifies these behaviors live: https://github.com/pennacle-security/summit#anti-false-positives-and-false-negatives

The scanner is literally an encoding of the maintainers' knowledge of common web vulnerability classes and their mitigations: SQL injection (remediation: parameterized queries), reflected XSS (context-aware output encoding + CSP), host header injection (build URLs from server-side config), CORS origin reflection (origin whitelisting), open redirect (server-side allowlists), path traversal (canonicalization), plus exploitation prerequisites like verbose error leaks and cookie flags. Every Finding carries a concrete remediation string: https://github.com/pennacle-security/summit/tree/main/summit/scan/modules

Summit implements no cryptographic algorithms itself. Its only crypto-adjacent behavior is HTTPS scanning, performed entirely by the underlying TLS stack (OpenSSL via requests/urllib3) - publicly published and expert-reviewed. base64/hex in the toolkit are encodings, not cryptography; JWT decoding is verification-free parsing and is labeled as such.

Correct by construction: summit never re-implements cryptography. All TLS is delegated to the requests/urllib3/OpenSSL stack, which exists specifically to implement cryptographic transport. The toolkit performs encodings (base64, hex, URL) and parses JWT structure without touching any signature verification.

All crypto-adjacent functionality comes from FLOSS components: requests (Apache-2.0), urllib3 (MIT) and the OpenSSL stack. Nothing depends on proprietary cryptography.

N/A - summit implements no cryptographic mechanisms, generates no keys, and stores no secrets. Keylength policy does not apply.

N/A - no cryptographic algorithms are implemented or configured by this project; no broken algorithms are used anywhere.

N/A - summit configures no cipher suites or hash algorithms of its own; TLS negotiation is delegated entirely to the underlying OpenSSL stack and the scanned server.

N/A - summit performs no key agreement; any forward secrecy is a property of the TLS stack and the scanned server, not of this project.

N/A - summit has no user accounts, does not authenticate external users, and never stores passwords.

N/A - summit generates no cryptographic keys or nonces. (The fuzzer's wildcard-baseline marker is a fixed constant string, not a security value.)

Distribution channels use HTTPS exclusively. [osps_br_03_02]

All distribution is over HTTPS: the source is obtained via git clone https://github.com/pennacle-security/summit.git (TLS) and releases via GitHub release assets (TLS). No hashes are published over plain HTTP anywhere; there is no unsigned-hash-over-http channel to misuse.

No unpatched vulnerabilities of any severity are publicly known for summit. Preventive and detective controls run continuously: CodeQL (Python) on every push, Dependabot for pip and action dependencies, OpenSSF Scorecard weekly, and private vulnerability reporting with a 72-hour acknowledgment / 14-day fix commitment: https://github.com/pennacle-security/.github/blob/main/SECURITY.md

No critical vulnerabilities have been reported to date. The published policy commits to acknowledgment within 72 hours and a fix or mitigation plan within 14 days of any confirmed report: https://github.com/pennacle-security/.github/blob/main/SECURITY.md

No credentials exist in the repositories: CI uses the ephemeral GITHUB_TOKEN automatically provided by GitHub Actions (no stored PATs), no private keys or passwords are present in any tracked file, and GitHub's secret scanning with push protection is active on the repository - a push containing a credential would be blocked before it lands.

CodeQL (semantic static analysis, well beyond lint warnings) runs on every push to main, every pull request, and on a weekly schedule: https://github.com/pennacle-security/summit/blob/main/.github/workflows/codeql.yml - results are uploaded to GitHub code scanning. A second layer, ruff (pycodestyle + pyflakes), gates every push before tests run: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml

CodeQL's Python analysis includes its security query suite - taint-tracking queries that look for exactly the common vulnerability classes in this kind of software: SQL injection, URL/redirect injection from user input, server-side request forgery, cleartext logging of sensitive data, and unsafe deserialization. Alert results are published to the repository's code scanning view: https://github.com/pennacle-security/summit/security/code-scanning

CodeQL has reported no medium-or-higher severity findings to date. The published policy is that confirmed findings are fixed immediately after confirmation (acknowledgment within 72 hours, fix or mitigation within 14 days): https://github.com/pennacle-security/.github/blob/main/SECURITY.md - any future alerts will be visible publicly at the code scanning view.

Static analysis runs on every commit to main and every pull request (CodeQL + ruff), plus a weekly scheduled CodeQL scan (cron "17 4 * * 3") - exceeding the "every commit or at least daily" bar: https://github.com/pennacle-security/summit/blob/main/.github/workflows/codeql.yml

Every push runs the software live and observes its behavior against a deliberately vulnerable target: the demo-scan smoke test executes a full summit scan (crawler + passive + active checks + link health) against examples/vuln_app.py and gates the results, and the evidence runner dynamically verifies 11 behavior claims (rate limiter pacing, WAF bypass at the HTTP level, retries against a live 429-then-200 server, concurrency on a latency-bearing target). The tool itself is a web application scanner, so its dynamic-analysis surface is dogfooded in CI: https://github.com/pennacle-security/summit/blob/main/.github/workflows/tests.yml

N/A - summit is written entirely in Python, a memory-safe language. No C, C++ or other memory-unsafe code is produced by this project.

Python has assertions enabled by default in every run (no optimized/no-assert builds exist for this project), and the CI configuration maximizes them: 45 pytest tests (pytest rewrites and enforces every assert), the smoke test asserts seeded detections and the negative control, and the evidence runner asserts 11 behavior claims with measured numbers. Assertions are always on - there is no production build variant that strips them.

N/A in practice: no medium-or-higher severity exploitable vulnerabilities have been discovered by dynamic analysis to date. The standing policy for any confirmed dynamic-analysis finding is immediate remediation (fix or mitigation plan within 14 days): https://github.com/pennacle-security/.github/blob/main/SECURITY.md