zetetic-team-subagents

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

There is no set of practices that can guarantee that software will never have defects or vulnerabilities; even formal methods can fail if the specifications or assumptions are wrong. Nor is there any set of practices that can guarantee that a project will sustain a healthy and well-functioning development community. However, following best practices can help improve the results of projects. For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different companies. To earn a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR be unmet with justification, and all SUGGESTED criteria must be met OR unmet (we want them considered at least). If you want to enter justification text as a generic comment, instead of being a rationale that the situation is acceptable, start the text block with '//' followed by a space. Feedback is welcome via the GitHub site as issues or pull requests There is also a mailing list for general discussion.

We gladly provide the information in several locales, however, if there is any conflict or inconsistency between the translations, the English version is the authoritative version.
If this is your project, please show your badge status on your project page! The badge status looks like this: Badge level for project 13847 is silver Here is how to embed it:
You can show your badge status by embedding this in your markdown file:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13847/badge)](https://www.bestpractices.dev/projects/13847)
or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/13847"><img src="https://www.bestpractices.dev/projects/13847/badge"></a>


These are the Silver level criteria. You can also view the Passing or Gold level criteria.

Baseline Series: Baseline Level 1 Baseline Level 2 Baseline Level 3

        

 Basics 17/17 ●

  • General

    Note that other projects may use the same name.

    Cross-platform evidence synthesis for Codex, Gemini CLI, and Claude Code, plus a full Claude-native agent and gate distribution. 11 problem-shaped skills backed by 97 sourced reasoning patterns; commit-time checks block unsourced constants. “I do not know” is a supported outcome.

    Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.
    If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".
    The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.

  • Prerequisites


    Enough for a badge!

    The project MUST achieve a passing level badge. [achieve_passing]

  • Basic project website content


    Enough for a badge!

    The information on how to contribute MUST include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]

    CONTRIBUTING.md states the requirements a contribution must meet: the coding standard it is held to (https://github.com/cdeust/zetetic-team-subagents/blob/main/rules/coding-standards.md), the five sections every new agent definition must answer, the hook rules, and the testing expectation. https://github.com/cdeust/zetetic-team-subagents/blob/main/CONTRIBUTING.md


  • Project oversight


    Barely enough for a badge.

    The project SHOULD have a legal mechanism where all developers of non-trivial amounts of project software assert that they are legally authorized to make these contributions. The most common and easily-implemented approach for doing this is by using a Developer Certificate of Origin (DCO), where users add "signed-off-by" in their commits and the project links to the DCO website. However, this MAY be implemented as a Contributor License Agreement (CLA), or other legal mechanism. (URL required) [dco]
    The DCO is the recommended mechanism because it's easy to implement, tracked in the source code, and git directly supports a "signed-off" feature using "commit -s". To be most effective it is best if the project documentation explains what "signed-off" means for that project. A CLA is a legal agreement that defines the terms under which intellectual works have been licensed to an organization or project. A contributor assignment agreement (CAA) is a legal agreement that transfers rights in an intellectual work to another party; projects are not required to have CAAs, since having CAA increases the risk that potential contributors will not contribute, especially if the receiver is a for-profit organization. The Apache Software Foundation CLAs (the individual contributor license and the corporate CLA) are examples of CLAs, for projects which determine that the risks of these kinds of CLAs to the project are less than their benefits.

    There is no DCO or CLA requirement today. All non-trivial code is written by the sole maintainer, who owns the copyright and licenses it under MIT; the authorship statement is at https://github.com/cdeust/zetetic-team-subagents#license. A DCO sign-off requirement is the intended mechanism once outside contributors start submitting non-trivial changes.


    Enough for a badge!

    The project MUST clearly define and document its project governance model (the way it makes decisions, including key roles). (URL required) [governance]
    There needs to be some well-established documented way to make decisions and resolve disputes. In small projects, this may be as simple as "the project owner and lead makes all final decisions". There are various governance models, including benevolent dictator and formal meritocracy; for more details, see Governance models. Both centralized (e.g., single-maintainer) and decentralized (e.g., group maintainers) approaches have been successfully used in projects. The governance information does not need to document the possibility of creating a project fork, since that is always possible for FLOSS projects.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/GOVERNANCE.md documents the decision model. Who merges: the maintainer, the only account with write access to main. What a change needs to land: every hard CI gate green on the exact pushed tree (agent-definition auditor, craftsmanship checker on newly-added files, redaction sweep, documented-commands and documented-counts gates, tools regression suites, memory and worktree suites, shellcheck at error and warning severity, CodeQL), plus a completion ledger mapping every code path in the diff to the test or command that proves it (rules/coding-standards.md section 13). How disagreements resolve: on evidence in the open, and where evidence does not settle it the maintainer decides and records the reasoning. The document also states why there is no second-reviewer requirement (GitHub forbids self-approval, so requiring reviews on a single-maintainer repository would deadlock every merge, as already analysed in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/SCORECARD.md) and says plainly that the gates are a weaker guarantee than human review rather than presenting them as equivalent.


    Enough for a badge!

    The project MUST adopt a code of conduct and post it in a standard location. (URL required) [code_of_conduct]
    Projects may be able to improve the civility of their community and to set expectations about acceptable conduct by adopting a code of conduct. This can help avoid problems before they occur and make the project a more welcoming place to encourage contributions. This should focus only on behavior within the community/workplace of the project. Example codes of conduct are the Linux kernel code of conduct, the Contributor Covenant Code of Conduct, the Debian Code of Conduct, the Ubuntu Code of Conduct, the Fedora Code of Conduct, the GNOME Code Of Conduct, the KDE Community Code of Conduct, the Python Community Code of Conduct, The Ruby Community Conduct Guideline, and The Rust Code of Conduct.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/CODE_OF_CONDUCT.md, at the standard repository location, with reporting and enforcement sections. The reporting sentence points at a package.json that does not exist in this repository; that broken pointer is tracked in issue #73, and the private channel in https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md works today.


    Enough for a badge!

    The project MUST clearly define and publicly document the key roles in the project and their responsibilities, including any tasks those roles must perform. It MUST be clear who has which role(s), though this might not be documented in the same way. (URL required) [roles_responsibilities]
    The documentation for governance and roles and responsibilities may be in one place.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/GOVERNANCE.md#roles-and-responsibilities is a table of three roles, what each is responsible for, and who holds it. Maintainer: Clement Deust (@cdeust, admin@ai-architect.tools), who triages and closes issues, reviews and merges pull requests, cuts releases, owns the security disclosure channel and its response SLA, enforces the code of conduct, and sets the roadmap. Contributor: anyone opening an issue or pull request, holding no repository permissions. Security reporter: anyone using the private channel in SECURITY.md. The document states that the bus factor is 1 and that every role requiring a permission is held by one person, matching what docs/SCORECARD.md and the bus_factor answer here already say, rather than being softened in one place and admitted in another.


    Enough for a badge!

    The project MUST be able to continue with minimal interruption if any one person dies, is incapacitated, or is otherwise unable or unwilling to continue support of the project. In particular, the project MUST be able to create and close issues, accept proposed changes, and release versions of software, within a week of confirmation of the loss of support from any one individual. This MAY be done by ensuring someone else has any necessary keys, passwords, and legal rights to continue the project. Individuals who run a FLOSS project MAY do this by providing keys in a lockbox and a will providing any needed legal rights (e.g., for DNS names). (URL required) [access_continuity]

    GOVERNANCE.md documents the credential-free continuation path. The complete source, history, tests, standards, marketplace manifests, and release workflow are public under MIT. A successor can fork the repository, enable and manage Issues, accept pull requests, and publish an attested tagged release under the fork's own GitHub OIDC identity within a week; no original key, token, private dependency, build service, or legal assignment is required. Users install from the continuation repository and past releases remain independently verifiable through SHA-256 and Sigstore transparency-log attestations. @cdeust remains the only administrator of the original repository, so the bus factor is honestly 1 and preserving the original URL/listing is weaker than with a second maintainer; that does not prevent continuation of the project results and all three operational capabilities. https://github.com/cdeust/zetetic-team-subagents/blob/main/GOVERNANCE.md#continuity-of-access


    Barely enough for a badge.

    The project SHOULD have a "bus factor" of 2 or more. (URL required) [bus_factor]
    A "bus factor" (aka "truck factor") is the minimum number of project members that have to suddenly disappear from a project ("hit by a bus") before the project stalls due to lack of knowledgeable or competent personnel. The truck-factor tool can estimate this for projects on GitHub. For more information, see Assessing the Bus Factor of Git Repositories by Cosentino et al.

    The bus factor is 1. This is a single-maintainer project, stated plainly rather than papered over. The same constraint is already recorded in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/SCORECARD.md, which explains why the Scorecard Code-Review and Branch-Protection checks are structurally unreachable here: GitHub does not permit self-approval, so requiring reviews would deadlock every merge. Review rigor is carried instead by the always-on hard CI gates.


  • Documentation


    Enough for a badge!

    The project MUST have a documented roadmap that describes what the project intends to do and not do for at least the next year. (URL required) [documentation_roadmap]
    The project might not achieve the roadmap, and that's fine; the purpose of the roadmap is to help potential users and contributors understand the intended direction of the project. It need not be detailed.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/ROADMAP.md covers the twelve months from 2026-07-28 to 2027-07-28 and states both halves the criterion asks for. What the project intends to do: finish OpenSSF silver, with the two original MUST blockers now recorded as completed, then address the remaining unmet-but-fixable criteria version_tags_signed and dynamic_analysis; hold Python coverage above its blocking 80 percent floor and move to mutation testing as the strength measure; produce a recorded end-to-end run of the autonomous build loop against a repository that does not contain this tooling; and grow the agent and skill roster under the counting gate. Each item states a Done-when condition naming the artifact that would exist or the number that would move, so a reader can check later whether it happened. What the project will not do, each as a decision with its reasoning: no sandboxing or runtime enforcement of agent refusal conditions, no hosts other than Claude Code, no hosted service or telemetry or accounts, and no localization. Gold is explicitly not promised in the window, because its three blockers all reduce to the single-maintainer fact, which depends on another person's willingness rather than on effort. Linked from the README documentation list.


    Enough for a badge!

    The project MUST include documentation of the architecture (aka high-level design) of the software produced by the project. If the project does not produce software, select "not applicable" (N/A). (URL required) [documentation_architecture]
    A software architecture explains a program's fundamental structures, i.e., the program's major components, the relationships among them, and the key properties of these components and relationships.

    The architecture is documented at two levels. The component model and how the pieces compose is in the README (https://github.com/cdeust/zetetic-team-subagents#what-you-actually-get and https://github.com/cdeust/zetetic-team-subagents#knowledge-ingestion--a-query-indexed-semantic-layer, which gives the web_ingest to manifest_gate to semantic_layer pipeline and states that the three tools import none of each other, with the skill as the single wiring point). The agent file shape, frontmatter contract and routing mechanism are specified in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/AGENT-INTERNALS.md, and the memory subsystem's scopes, ACL and MCP surface in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/MEMORY-MCP.md


    Enough for a badge!

    The project MUST document what the user can and cannot expect in terms of security from the software produced by the project (its "security requirements"). (URL required) [documentation_security]
    These are the security requirements that the software is intended to meet.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md states what the user can and cannot expect. It opens by naming what installing the plugin grants (session-execution rights, no sandbox between a modified file and the machine), lists the supply-chain assurances and how to verify each, and closes with an explicit "What this does NOT claim" paragraph: provenance proves who built the bundle and from which commit, not that the scripts are free of defects, and it is worth nothing to a user who never runs the verification.


    Enough for a badge!

    The project MUST provide a "quick start" guide for new users to help them quickly do something with the software. (URL required) [documentation_quick_start]
    The idea is to show users how to get started and make the software do anything at all. This is critically important for potential users to get started.

    Two commands and the system is installed: https://github.com/cdeust/zetetic-team-subagents#install. A narrower quick start for the gates alone (claude plugin install zetetic-gates) is on the same page, and the first thing to do with it is the reproducible one-liner at https://github.com/cdeust/zetetic-team-subagents#the-system-enforcing-its-own-standard


    Enough for a badge!

    The project MUST make an effort to keep the documentation consistent with the current version of the project results (including software produced by the project). Any known documentation defects making it inconsistent MUST be fixed. If the documentation is generally current, but erroneously includes some older information that is no longer true, just treat that as a defect, then track and fix as usual. [documentation_current]
    The documentation MAY include information about differences or changes between versions of the software and/or link to older versions of the documentation. The intent of this criterion is that an effort is made to keep the documentation consistent, not that the documentation must be perfect.

    Fixed and now gated. The four disagreeing totals are reconciled against a written counting convention (https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/COUNTING.md), which defines every quantity with the exact command that produces it and records the judgement calls: an agent is a file carrying a name field, so agents/genius/INDEX.md is excluded as the routing table it is; skills are counted as 11 problem-shaped entry points plus 65 category procedures totalling 76; and hooks are stated as two distinct quantities, 19 lifecycle registrations in hooks/hooks.json and 20 scripts on disk, which is what README and marketplace.json were each half-right about. Measured on 2026-07-28: 97 genius agents, 23 team agents, 120 agents total, 76 skills, 19 hook registrations, 20 hook scripts, 26 commands, 44 tools, 28 test suites. Every claim in README.md, CONTRIBUTING.md and marketplace.json now agrees. Recurrence is closed by tools/doc-count-check.sh, a hard CI gate that recomputes all 25 claim instances and fails on drift; it also fails when a registered pattern matches nothing, so rewording copy cannot silently leave a claim unchecked. Unreproducible test-count claims (a tests-288 badge and a 241-tests line) were replaced by the suite count, which a command actually reports.


    Enough for a badge!

    The project repository front page and/or website MUST identify and hyperlink to any achievements, including this best practices badge, within 48 hours of public recognition that the achievement has been attained. (URL required) [documentation_achievements]
    An achievement is any set of external criteria that the project has specifically worked to meet, including some badges. This information does not need to be on the project website front page. A project using GitHub can put achievements on the repository front page by adding them to the README file.

    The repository front page carries a badge row that identifies and hyperlinks the project's achievements: the live OpenSSF Best Practices badge for this project (https://www.bestpractices.dev/projects/13847), live CI status, the test, agent, skill and hook counts, and the MIT license (https://github.com/cdeust/zetetic-team-subagents#readme). The badge is dynamic, so the level it displays tracks this questionnaire without a further edit. Per-release achievements are recorded in https://github.com/cdeust/zetetic-team-subagents/blob/main/CHANGELOG.md and the security posture in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/SCORECARD.md


  • Accessibility and internationalization


    Enough for a badge!

    The project (both project sites and project results) SHOULD follow accessibility best practices so that persons with disabilities can still participate in the project and use the project results where it is reasonable to do so. [accessibility_best_practices]
    For web applications, see the Web Content Accessibility Guidelines (WCAG 2.0) and its supporting document Understanding WCAG 2.0; see also W3C accessibility information. For GUI applications, consider using the environment-specific accessibility guidelines (such as Gnome, KDE, XFCE, Android, iOS, Mac, and Windows). Some TUI applications (e.g. `ncurses` programs) can do certain things to make themselves more accessible (such as `alpine`'s `force-arrow-cursor` setting). Most command-line applications are fairly accessible as-is. This criterion is often N/A, e.g., for program libraries. Here are some examples of actions to take or issues to consider:
    • Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language ( WCAG 2.0 guideline 1.1)
    • Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. ( WCAG 2.0 guideline 1.4.1)
    • The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for large text, incidental text, and logotypes ( WCAG 2.0 guideline 1.4.3)
    • Make all functionality available from a keyboard (WCAG guideline 2.1)
    • A GUI or web-based project SHOULD test with at least one screen-reader on the target platform(s) (e.g. NVDA, Jaws, or WindowEyes on Windows; VoiceOver on Mac & iOS; Orca on Linux/BSD; TalkBack on Android). TUI programs MAY work to reduce overdraw to prevent redundant reading by screen-readers.

    The project results have no graphical interface: they are Markdown definitions and command-line scripts whose output is plain text rendered by the host terminal. The project site is GitHub and the documentation is Markdown; the one image on the front page, the banner, carries a text alternative (alt="Zetetic Agents: 97 reasoning patterns, one epistemic standard").


    Barely enough for a badge.

    The software produced by the project SHOULD be internationalized to enable easy localization for the target audience's culture, region, or language. If internationalization (i18n) does not apply (e.g., the software doesn't generate text intended for end-users and doesn't sort human-readable text), select "not applicable" (N/A). [internationalization]
    Localization "refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale)." Internationalization is the "design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language." (See W3C's "Localization vs. Internationalization".) Software meets this criterion simply by being internationalized. No localization for another specific language is required, since once software has been internationalized it's possible for others to work on localization.

    The tools' user-facing strings (checker findings, hook notices, setup output) are English literals and are not externalized for localization, and the agent and skill definitions are English prose. Externalizing them has not been done, so this is reported unmet rather than claimed.


  • Other


    Enough for a badge!

    If the project sites (website, repository, and download URLs) store passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). If the project sites do not store passwords for this purpose, select "not applicable" (N/A). [sites_password_security]
    Note that the use of GitHub meets this criterion. This criterion only applies to passwords used for authentication of external users into the project sites (aka inbound authentication). If the project sites must log in to other sites (aka outbound authentication), they may need to store authorization tokens for that purpose differently (since storing a hash would be useless). This applies criterion crypto_password_storage to the project sites, similar to sites_https.

    The project operates no site of its own that authenticates external users. The repository and the download URLs are GitHub, and no password is stored by this project.


 Change Control 1/1 ●

 Reporting 3/3 ●

  • Bug-reporting process


    Enough for a badge!

    The project MUST use an issue tracker for tracking individual issues. [report_tracker]

    GitHub Issues: https://github.com/cdeust/zetetic-team-subagents/issues


  • Vulnerability report process


    Enough for a badge!

    The project MUST give credit to the reporter(s) of all vulnerability reports resolved in the last 12 months, except for the reporter(s) who request anonymity. If there have been no vulnerabilities resolved in the last 12 months, select "not applicable" (N/A). (URL required) [vulnerability_report_credit]

    No vulnerability has been resolved in the last 12 months, so there is no reporter to credit. The commitment is documented: reporters are credited in the release notes for the patched version unless they request anonymity. https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md


    Enough for a badge!

    The project MUST have a documented process for responding to vulnerability reports. (URL required) [vulnerability_response_process]
    This is strongly related to vulnerability_report_process, which requires that there be a documented way to report vulnerabilities. It also related to vulnerability_report_response, which requires response to vulnerability reports within a certain time frame.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md documents the whole response process: the private advisory channel, what a report must contain, a per-severity SLA table (24 hours first response and 7 days to patch for critical, 3 and 14 days for high), a five-step disclosure timeline with a 30-day default coordinated date, and what is out of scope.


 Quality 19/19 ●

  • Coding standards


    Enough for a badge!

    The project MUST identify the specific coding style guides for the primary languages it uses, and require that contributions generally comply with it. (URL required) [coding_standards]
    In most cases this is done by referring to some existing style guide(s), possibly listing differences. These style guides can include ways to improve readability and ways to reduce the likelihood of defects (including vulnerabilities). Many programming languages have one or more widely-used style guides. Examples of style guides include Google's style guides and SEI CERT Coding Standards.

    The standard is a document in the tree, not a preference: https://github.com/cdeust/zetetic-team-subagents/blob/main/rules/coding-standards.md covers SOLID, the layer dependency rule, size limits, dependency injection, local reasoning, source discipline, mutation testing, the definition of done and the boy-scout rule, each with its primary source. CONTRIBUTING.md names it as binding and excerpts the load-bearing rules: https://github.com/cdeust/zetetic-team-subagents/blob/main/CONTRIBUTING.md


    Enough for a badge!

    The project MUST automatically enforce its selected coding style(s) if there is at least one FLOSS tool that can do so in the selected language(s). [coding_standards_enforced]
    This MAY be implemented using static analysis tool(s) and/or by forcing the code through code reformatters. In many cases the tool configuration is included in the project's repository (since different projects may choose different configurations). Projects MAY allow style exceptions (and typically will); where exceptions occur, they MUST be rare and documented in the code at their locations, so that these exceptions can be reviewed and so that tools can automatically handle them in the future. Examples of such tools include ESLint (JavaScript), Rubocop (Ruby), and devtools check (R).

    Enforced automatically at two points. At commit time https://github.com/cdeust/zetetic-team-subagents/blob/main/hooks/pre-commit-zetetic.sh runs tools/zetetic-checker.sh on the staged diff and returns exit 2 on a violation. In CI four hard gates block the merge (https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/ci.yml): the craftsmanship checker on newly added files, the redaction sweep on the full tree under ZETETIC_PROFILE=strict, the tools regression suite, and shellcheck at error severity. The ratchet shape (new files gated, legacy debt reported) is documented in the workflow itself.


  • Working build system


    Enough for a badge!

    Build systems for native binaries MUST honor the relevant compiler and linker (environment) variables passed in to them (e.g., CC, CFLAGS, CXX, CXXFLAGS, and LDFLAGS) and pass them to compiler and linker invocations. A build system MAY extend them with additional flags; it MUST NOT simply replace provided values with its own. If no native binaries are being generated, select "not applicable" (N/A). [build_standard_variables]
    It should be easy to enable special build features like Address Sanitizer (ASAN), or to comply with distribution hardening best practices (e.g., by easily turning on compiler flags to do so).

    No native binaries are generated. There is no compiler or linker invocation anywhere in the project, so CC, CFLAGS and LDFLAGS have nothing to apply to.


    Enough for a badge!

    The build and installation system SHOULD preserve debugging information if they are requested in the relevant flags (e.g., "install -s" is not used). If there is no build or installation system (e.g., typical JavaScript libraries), select "not applicable" (N/A). [build_preserve_debug]
    E.G., setting CFLAGS (C) or CXXFLAGS (C++) should create the relevant debugging information if those languages are used, and they should not be stripped during installation. Debugging information is needed for support and analysis, and also useful for measuring the presence of hardening features in the compiled binaries.

    There is no build or installation system that strips anything. The software is Markdown and scripts, installed by copying, and the source on disk is what runs.


    Enough for a badge!

    The build system for the software produced by the project MUST NOT recursively build subdirectories if there are cross-dependencies in the subdirectories. If there is no build or installation system (e.g., typical JavaScript libraries), select "not applicable" (N/A). [build_non_recursive]
    The project build system's internal dependency information needs to be accurate, otherwise, changes to the project may not build correctly. Incorrect builds can lead to defects (including vulnerabilities). A common mistake in large build systems is to use a "recursive build" or "recursive make", that is, a hierarchy of subdirectories containing source files, where each subdirectory is independently built. Unless each subdirectory is fully independent, this is a mistake, because the dependency information is incorrect.

    There is no build system, so there are no subdirectory builds to make recursive or otherwise.


    Enough for a badge!

    The project MUST be able to repeat the process of generating information from source files and get exactly the same bit-for-bit result. If no building occurs (e.g., scripting languages where the source code is used directly instead of being compiled), select "not applicable" (N/A). [build_repeatable]
    GCC and clang users may find the -frandom-seed option useful; in some cases, this can be resolved by forcing some sort order. More suggestions can be found at the reproducible build site.

    Although nothing is compiled, the one thing that is generated is bit-for-bit reproducible by construction. https://github.com/cdeust/zetetic-team-subagents/blob/main/tools/build-release-bundle.sh creates the release tarball with --sort=name --mtime=@0 --owner=0 --group=0 --numeric-owner, so the archive does not depend on filesystem order, timestamps or the building user. The script says why: an attestation over a non-deterministic archive proves nothing a second builder can check.


  • Installation system


    Enough for a badge!

    The project MUST provide a way to easily install and uninstall the software produced by the project using a commonly-used convention. [installation_common]
    Examples include using a package manager (at the system or language level), "make install/uninstall" (supporting DESTDIR), a container in a standard format, or a virtual machine image in a standard format. The installation and uninstallation process (e.g., its packaging) MAY be implemented by a third party as long as it is FLOSS.

    Installed and uninstalled through the ecosystem's package manager: "claude plugin marketplace add cdeust/zetetic-team-subagents" then "claude plugin install zetetic-team-subagents" (https://github.com/cdeust/zetetic-team-subagents#install). The manual path is https://github.com/cdeust/zetetic-team-subagents/blob/main/scripts/setup.sh with install, update, uninstall and configure verbs, and the installer writes a manifest so that uninstall removes exactly what it added.


    Enough for a badge!

    The installation system for end-users MUST honor standard conventions for selecting the location where built artifacts are written to at installation time. For example, if it installs files on a POSIX system it MUST honor the DESTDIR environment variable. If there is no installation system or no standard convention, select "not applicable" (N/A). [installation_standard_variables]

    There is no installation system that writes built artifacts to a configurable prefix. Installation copies agents, skills, hooks and tools into the host's own plugin directory under ~/.claude, which is the convention the host defines, so DESTDIR and similar variables have nothing to select.


    Enough for a badge!

    The project MUST provide a way for potential developers to quickly install all the project results and support environment necessary to make changes, including the tests and test environment. This MUST be performed with a commonly-used convention. [installation_development_quick]
    This MAY be implemented using a generated container and/or installation script(s). External dependencies would typically be installed by invoking system and/or language package manager(s), per external_dependencies.

    git clone and the software is complete: nothing is compiled and there are no dependencies to resolve. https://github.com/cdeust/zetetic-team-subagents/blob/main/CONTRIBUTING.md lists the prerequisites (bash 4+, GNU coreutils, ripgrep, python3) and https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/ci.yml gives the exact command for every suite, which is the same command a developer runs locally. The stale command list inside CONTRIBUTING is being corrected under issue #73.


  • Externally-maintained components


    Enough for a badge!

    The project MUST list external dependencies in a computer-processable way. (URL required) [external_dependencies]
    Typically this is done using the conventions of package manager and/or build system. Note that this helps implement installation_development_quick.

    Listed in two computer-processable forms. Every release publishes a CycloneDX SBOM (zetetic-team-subagents.cdx.json) inventorying every bundled file with its hash, including the vendored third-party skill material, alongside an EXECUTABLE-MANIFEST.sha256 that enumerates every hook and tool that will run on the user's machine (https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md). The only external supply-chain surface, the GitHub Actions, is declared in https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/dependabot.yml and each action is pinned to a full commit SHA in the workflows.


    Enough for a badge!

    Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix exploitable vulnerabilities or verify them as unexploitable. [dependency_monitoring]
    This can be done using an origin analyzer / dependency checking tool / software composition analysis tool such as OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis, and Bundler-audit (for Ruby). Some package managers include mechanisms to do this. It is acceptable if the components' vulnerability cannot be exploited, but this analysis is difficult and it is sometimes easier to simply update or fix the part.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/dependabot.yml runs weekly against the github-actions ecosystem, which is this project's only external dependency surface: there is no runtime package to install, so there is no pip or npm manifest to watch, and the config states that reasoning rather than declaring an empty ecosystem. Dependabot updates the pinned SHA and rewrites the version comment in place, so pinning discipline is preserved automatically. OpenSSF Scorecard runs on a schedule on top of it (https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/scorecard.yml), with each finding's disposition recorded in https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/SCORECARD.md


    Enough for a badge!

    The project MUST either:
    1. make it easy to identify and update reused externally-maintained components; or
    2. use the standard components provided by the system or programming language.
    Then, if a vulnerability is found in a reused component, it will be easy to update that component. [updateable_reused_components]
    A typical way to meet this criterion is to use system and programming language package management systems. Many FLOSS programs are distributed with "convenience libraries" that are local copies of standard libraries (possibly forked). By itself, that's fine. However, if the program *must* use these local (forked) copies, then updating the "standard" libraries as a security update will leave these additional copies still vulnerable. This is especially an issue for cloud-based systems; if the cloud provider updates their "standard" libraries but the program won't use them, then the updates don't actually help. See, e.g., "Chromium: Why it isn't in Fedora yet as a proper package" by Tom Callaway.

    Reused components are identifiable and updateable. The GitHub Actions are pinned by full commit SHA with a version comment and updated by Dependabot weekly. The Python code imports only the standard library, so there is no vendored runtime dependency to go stale. The one convenience copy, the vendored writing and redaction rule material, carries its provenance in the file and is inventoried in the per-release CycloneDX SBOM.


    Enough for a badge!

    The project SHOULD avoid using deprecated or obsolete functions and APIs where FLOSS alternatives are available in the set of technology it uses (its "technology stack") and to a supermajority of the users the project supports (so that users have ready access to the alternative). [interfaces_current]

    The technology stack is current and nothing deprecated is relied on. The Python is standard library only (argparse, hashlib, json, ssl, subprocess, urllib, xml.etree, tempfile) with no deprecated or removed module, and CI pins Python 3.12. The shell targets bash 4+ with POSIX coreutils, and shellcheck at error severity would flag obsolete constructs on every push.


  • Automated test suite


    Enough for a badge!

    An automated test suite MUST be applied on each check-in to a shared repository for at least one branch. This test suite MUST produce a report on test success or failure. [automated_integration_testing]
    This requirement can be viewed as a subset of test_continuous_integration, but focused on just testing, without requiring continuous integration.

    Every push to main and every pull request runs the full gate set and reports pass or fail per job: seven jobs in https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/ci.yml (memory suites, agent auditor, worktree tests, zetetic checker, craftsmanship checker, redaction sweep, tools regression suite covering 16 suites), plus shellcheck and CodeQL in their own workflows. Four of them are hard gates that block the merge. The Python pytest suites are the one part not yet wired into CI, tracked in issue #71.


    Enough for a badge!

    The project MUST add regression tests to an automated test suite for at least 50% of the bugs fixed within the last six months. [regression_tests_added50]

    Well above 50 percent, because the standard makes it mandatory: rules/coding-standards.md section 13.1 G2 requires every bug fixed in a pull request to carry a regression test that fails on the pre-fix code. Recent fixes follow it: issue #64 (redaction-checker missing untracked files) shipped with the test that reproduces the false local pass, and issue #60's CodeQL fix was made structural so the checker itself is the regression guard. https://github.com/cdeust/zetetic-team-subagents/blob/main/rules/coding-standards.md


    Enough for a badge!

    The project MUST have FLOSS automated test suite(s) that provide at least 80% statement coverage if there is at least one FLOSS tool that can measure this criterion in the selected language. [test_statement_coverage80]
    Many FLOSS tools are available to measure test coverage, including gcov/lcov, Blanket.js, Istanbul, JCov, and covr (R). Note that meeting this criterion is not a guarantee that the test suite is thorough, instead, failing to meet this criterion is a strong indicator of a poor test suite.

    Measured on 2026-08-03 with coverage.py 7.15.2 and pytest 9.1.1 over the shipped Python surface declared in pyproject.toml (hooks/ plus tools/): 1607 statements, 50 missed, 97 percent, with 969 tests passing. The figure was 21 percent before issue #71, and the pytest suite did not run in CI at all, so a change that broke its tests landed green. Both are fixed. The suite now runs as a hard gate on push and pull_request (https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/ci.yml, job 'Python Suite + Coverage Gate'), and coverage.py runs in the same job with fail_under = 80, so the number is enforced rather than reported. Scope, the floor and the exclusions are declared in https://github.com/cdeust/zetetic-team-subagents/blob/main/pyproject.toml rather than passed as command-line flags, so a local run and CI cannot measure different things; the one exclusion, the one-shot scripts/patch_*.py migrations, is written down there with the reason. The current command exits 0 at 97 percent, proving the 80 percent floor remains satisfied after the HTTPS trust-boundary change.


  • New functionality testing


    Enough for a badge!

    The project MUST have a formal written policy that as major new functionality is added, tests for the new functionality MUST be added to an automated test suite. [test_policy_mandated]

    A formal written policy exists. rules/coding-standards.md section 13.1 A1 to A3 requires happy paths, every enumerated edge case and every failure path (including the emission of the signal itself) to map to a test, and section 13.2 makes the mapping a required artifact of the pull request. Section 13.3 enumerates the refusals, including that classifying a coverage gap in new code as a follow-up is blocking. https://github.com/cdeust/zetetic-team-subagents/blob/main/rules/coding-standards.md


    Enough for a badge!

    The project MUST include, in its documented instructions for change proposals, the policy that tests are to be added for major new functionality. [tests_documented_added]
    However, even an informal rule is acceptable as long as the tests are being added in practice.

    CONTRIBUTING.md states it for hooks ("Changes to that hook need a corresponding test in tests/") and rules/coding-standards.md section 13 states it generally, with the Completion Ledger as the mechanism that makes it checkable in review. https://github.com/cdeust/zetetic-team-subagents/blob/main/CONTRIBUTING.md and https://github.com/cdeust/zetetic-team-subagents/blob/main/rules/coding-standards.md


  • Warning flags


    Enough for a badge!

    Projects MUST be maximally strict with warnings in the software produced by the project, where practical. [warnings_strict]
    Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

    Maximally strict for the languages in use. shellcheck runs at error severity over every shell file in hooks/ and tools/ with no "|| true" escape, so a single finding fails the job: see the step "ShellCheck (error severity - hard gate)" in https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/shellcheck.yml. CodeQL runs the widest query pack, security-and-quality, rather than the default security-only pack. The redaction sweep runs under ZETETIC_PROFILE=strict, which promotes every finding to exit 1 (https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/ci.yml). Warning severity for shellcheck is currently informational, with the backlog measured and scheduled in issue #74.


 Security 13/13 ●

  • Secure development knowledge


    Enough for a badge!

    The project MUST implement secure design principles (from "know_secure_design"), where applicable. If the project is not producing software, select "not applicable" (N/A). [implement_secure_design]
    For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening "economy of mechanism" / keep it simple).

    The principles are implemented, with one stated exception. Fail-safe defaults: the memory ACL denies any write outside a scope's owner list and tools/manifest_gate.py rejects an ungrounded source with exit 3. Separation of privilege: the release job holds only id-token and attestations write, everything else is contents: read. Open design: the enforcement surface and its documented limits are public (https://github.com/cdeust/zetetic-team-subagents#what-this-system-does-not-do). Economy of mechanism: web_ingest, manifest_gate and semantic_layer import none of each other and are wired by a skill, so each is independently testable. The exception is complete mediation at one tool boundary, described under input_validation below.


  • Use basic good cryptographic practices

    Note that some software does not need to use cryptographic mechanisms. If your project produces software that (1) includes, activates, or enables encryption functionality, and (2) might be released from the United States (US) to outside the US or to a non-US-citizen, you may be legally required to take a few extra steps. Typically this just involves sending an email. For more information, see the encryption section of Understanding Open Source Technology & US Export Controls.

    Enough for a badge!

    The default security mechanisms within the software produced by the project MUST NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH). [crypto_weaknesses]
    Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.

    The only digest in the tree is SHA-256 and the only transport is the platform default TLS context. No SHA-1, no MD5, and no hand-selected cipher mode.


    Enough for a badge!

    The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3. [crypto_algorithm_agility]

    The project selects no cryptographic algorithm of its own. Transport algorithms are negotiated by the platform TLS stack and release signing is delegated to Sigstore, so there is no project-level choice for a user to switch.


    Enough for a badge!

    The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation. If the project never processes authentication credentials and private cryptographic keys, select "not applicable" (N/A). [crypto_credential_agility]

    The software processes no authentication credentials and holds no private keys. Release signing is keyless through Sigstore, where the signing certificate is short-lived and issued against the workflow's OIDC identity, so there is no stored private key to separate out or rotate.


    Enough for a badge!

    The software produced by the project SHOULD support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default, and only enabled if the user specifically configures it. If the software produced by the project does not support network communications, select "not applicable" (N/A). [crypto_used_network]

    All outbound web-ingest traffic is HTTPS-only by construction. https://github.com/cdeust/zetetic-team-subagents/blob/main/tools/web_ingest.py applies one allowlist before constructing a request, inside the redirect handler before urllib follows a target, on the final response URL before reading its body, and before admitting discovered links to a crawl. Plain HTTP and every non-HTTPS scheme fail closed as FetchError. tests/test_web_ingest.py proves caller-supplied HTTP is rejected without reaching the transport, an HTTPS-to-HTTP redirect is rejected, and an insecure final response URL is rejected before its body is read. Certificate and hostname verification remain enabled through ssl.create_default_context.


    Enough for a badge!

    The software produced by the project SHOULD, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. If the software does not use TLS, select "not applicable" (N/A). [crypto_tls12]

    Outbound TLS goes through ssl.create_default_context (https://github.com/cdeust/zetetic-team-subagents/blob/main/tools/web_ingest.py), whose minimum protocol version on the Python versions this project targets is TLS 1.2. The context is created once and reused for every fetch, including the robots.txt fetch, so no request escapes it.


    Enough for a badge!

    The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources. If the software does not use TLS, select "not applicable" (N/A). [crypto_certificate_verification]
    Note that incorrect TLS certificate verification is a common mistake. For more information, see "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" by Martin Georgiev et al. and "Do you trust this application?" by Michael Catanzaro.

    Certificate verification is on by default and is never disabled. ssl.create_default_context sets verify_mode to CERT_REQUIRED and check_hostname to True, and there is no CERT_NONE, no check_hostname = False and no unverified context anywhere in the tree. The context is preferentially built against certifi's CA bundle when available, falling back to the system store. https://github.com/cdeust/zetetic-team-subagents/blob/main/tools/web_ingest.py


    Enough for a badge!

    The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). If the software does not use TLS, select "not applicable" (N/A). [crypto_verification_private]

    No private information is ever sent. The outbound client transmits only a User-Agent, Accept-Encoding and the conditional-GET validators (If-None-Match, If-Modified-Since); it sends no cookie, no authorization header and no credential. Certificate verification is performed by the default context before any request body or header leaves, and no fetch is made outside that context.


  • Secure release


    Enough for a badge!

    The project MUST cryptographically sign releases of the project results intended for widespread use, and there MUST be a documented process explaining to users how they can obtain the public signing keys and verify the signature(s). The private key for these signature(s) MUST NOT be on site(s) used to directly distribute the software to the public. If releases are not intended for widespread use, select "not applicable" (N/A). [signed_releases]
    The project results include both source code and any generated deliverables where applicable (e.g., executables, packages, and containers). Generated deliverables MAY be signed separately from source code. These MAY be implemented as signed git tags (using cryptographic digital signatures). Projects MAY provide generated results separately from tools like git, but in those cases, the separate results MUST be separately signed.

    Every release is cryptographically signed through Sigstore and the verification path is documented. The release workflow attests the tarball, the executable manifest and the CycloneDX SBOM with actions/attest-build-provenance under a least-privilege OIDC identity, and self-verifies with the shipped verifier before publishing (https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/release.yml). Users verify with "gh attestation verify zetetic-team-subagents.tar.gz --repo cdeust/zetetic-team-subagents", documented at https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md. Signing is keyless, so no private key exists to be stored on the distribution site: the certificate is short-lived, issued by Fulcio against the workflow's identity, and logged in the Rekor transparency log.


    Barely enough for a badge.

    It is SUGGESTED that in the version control system, each important version tag (a tag that is part of a major release, minor release, or fixes publicly noted vulnerabilities) be cryptographically signed and verifiable as described in signed_releases. [version_tags_signed]

    Release tags are annotated but not cryptographically signed: "git tag -v v2.35.0" reports no signature. The release artifacts are covered instead, each with a SHA-256 companion and a Sigstore build-provenance attestation (https://github.com/cdeust/zetetic-team-subagents/blob/main/SECURITY.md). Signing the tags themselves would add a second, independent anchor and has not been set up.


  • Other security issues


    Enough for a badge!

    The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all. [input_validation]
    Note that comparing input against a list of "bad formats" (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be "anything at all" (e.g., a file uploader), but these would typically be rare.

    Untrusted input is validated at each trust boundary. The memory tool checks every scope write against an owner list, tools/manifest_gate.py rejects an ungrounded source with a non-zero exit, hooks bound their stdin reads, and the fetch path caps response size and redirect depth. The remaining URL gap is closed in https://github.com/cdeust/zetetic-team-subagents/blob/main/tools/web_ingest.py with an explicit allowlist: the value must be a non-empty string, parse as an absolute HTTPS URL, include a host and valid port, and contain no embedded username or password. The same check is re-applied to redirects, final response URLs and discovered links. tests/test_web_ingest.py covers HTTP, file and scheme-relative forms, missing hosts, embedded credentials, invalid ports, redirect downgrade and insecure final URLs, including negative proof that rejected caller input never reaches the transport.


    Barely enough for a badge.

    Hardening mechanisms SHOULD be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. [hardening]
    Hardening mechanisms may include HTTP headers like Content Security Policy (CSP), compiler flags to mitigate attacks (such as -fstack-protector), or compiler flags to eliminate undefined behavior. For our purposes least privilege is not considered a hardening mechanism (least privilege is important, but separate).

    This criterion counts mechanisms such as HTTP response headers and compiler hardening flags, and explicitly excludes least privilege. The project produces no HTTP surface for a Content Security Policy to apply to and compiles nothing, so there is no -fstack-protector equivalent to enable. The protections it does use (bounded stdin reads, a response-size cap, a redirect cap, fail-closed gates and a credential-path denylist on agent reads) are real, but they are not what this criterion measures, so it is reported unmet rather than argued into a pass.


    Enough for a badge!

    The project MUST provide an assurance case that justifies why its security requirements are met. The assurance case MUST include: a description of the threat model, clear identification of trust boundaries, an argument that secure design principles have been applied, and an argument that common implementation security weaknesses have been countered. (URL required) [assurance_case]
    An assurance case is "a documented body of evidence that provides a convincing and valid argument that a specified set of critical claims regarding a system’s properties are adequately justified for a given application in a given environment" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Trust boundaries are boundaries where data or execution changes its level of trust, e.g., a server's boundaries in a typical web application. It's common to list secure design principles (such as Saltzer and Schroeer) and common implementation security weaknesses (such as the OWASP top 10 or CWE/SANS top 25), and show how each are countered. The BadgeApp assurance case may be a useful example. This is related to documentation_security, documentation_architecture, and implement_secure_design.

    https://github.com/cdeust/zetetic-team-subagents/blob/main/docs/ASSURANCE-CASE.md provides the assurance case with all four required parts, each individually identifiable as its own section, and it is linked from both SECURITY.md and the README. Part 1, threat model: installing the plugin grants session-execution rights with no sandbox, which is the ecosystem's shortest path from a compromised artifact to code execution because the payload does not need to be compiled; four adversaries are tabulated with the capability assumed and what each is trying to reach, and three classes are placed explicitly out of scope. Part 2, trust boundaries: five are enumerated concretely for this system, each with what crosses it, what checks it and what the check does not cover, namely the release bundle to install path, the marketplace install into ~/.claude, hook invocation from the Claude Code lifecycle, tool invocation with model-supplied arguments, and the memory scope ACL. Part 3, secure design: fail-closed where failure is recoverable (including gates that treat an empty match set as failure, so a path bug cannot turn a gate into a silent green no-op), least privilege on agent reads, defence in depth on the artifact path, bounded consumption of untrusted input with sourced constants, validation at boundaries per the project's own coding standard, and no long-lived signing key anywhere in the project because Sigstore issues short-lived certificates against the workflow OIDC identity. Part 4, common implementation weaknesses: a table of eleven weakness classes against the counter applied and that counter's limit, covering shellcheck at error and warning severity with the linter pinned and checksum-verified, CodeQL, the path denylist, the redaction sweep, artifact attestation, resource caps, silent-no-op gates, untested error paths, mutation testing, SHA-pinned actions and Scorecard. Every claim states its limit in the style SECURITY.md already uses, including the places where a control is weaker than it looks: the secret shield fails open on malformed input by design, the memory ACL is permissive with no registry present and is bypassable by environment so it separates cooperating agents rather than bounding a hostile one, and the HTTPS allowlist is not a network sandbox. The document closes by stating that it has never been tested by a real attack and has had no independent review, since its author also wrote the code.


 Analysis 2/2 ●

  • Static code analysis


    Enough for a badge!

    The project MUST use at least one static analysis tool with rules or approaches to look for common vulnerabilities in the analyzed language or environment, if there is at least one FLOSS tool that can implement this criterion in the selected language. [static_analysis_common_vulnerabilities]
    Static analysis tools that are specifically designed to look for common vulnerabilities are more likely to find them. That said, using any static tools will typically help find some problems, so we are suggesting but not requiring this for the 'passing' level badge.

    CodeQL runs the security-and-quality suite, which is the security query pack plus the quality queries, rather than a generic lint. It found real vulnerability-class defects and they were fixed: 33 alerts cleared at source in issue #60. https://github.com/cdeust/zetetic-team-subagents/blob/main/.github/workflows/codeql.yml


  • Dynamic code analysis


    Enough for a badge!

    If the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) MUST be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). [dynamic_analysis_unsafe]
    Examples of mechanisms to detect memory safety problems include Address Sanitizer (ASAN) (available in GCC and LLVM), Memory Sanitizer, and valgrind. Other potentially-used tools include thread sanitizer and undefined behavior sanitizer. Widespread assertions would also work.

    The software is bash and Python. There is no C, C++ or other memory-unsafe code for a memory-safety dynamic analyser to target.



You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/13847/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. See our automation proposals system for how to do that. This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Clement and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Clement.
Entry created on 2026-07-27 22:32:34 UTC, last updated on 2026-08-03 00:36:11 UTC. Last achieved passing badge on 2026-07-27 22:58:12 UTC.