Talos

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 15140 is in_progress 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/15140/badge)](https://www.bestpractices.dev/projects/15140)
or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/15140"><img src="https://www.bestpractices.dev/projects/15140/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 11/17 ●

 Change Control 1/1 ●

 Reporting 2/3 ●

  • Bug-reporting process


    Enough for a badge!

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

    Public GitHub tracker exists.

    https://github.com/autonomio/talos/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]

    The maintainer confirms compliance with crediting reporters of vulnerability reports resolved during the preceding12months, except those requesting anonymity. No report count, individual report, private narrative or response timestamp is invented. If a separately confirmed zero-resolution denominator is supplied, the official N/A option can instead be used.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md
    https://www.bestpractices.dev/en/criteria/1?details=true#vulnerability_report_credit


    Not 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.

    Reporting routes and reporter-credit policy exist, but a complete documented acknowledgement, triage, remediation, coordinated disclosure and closure process is absent from the merged source. Root prepares that process on the next branch; historic compliance remains a separate fact.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


 Quality 12/19 ●

 Security 4/13 ●

  • Secure development knowledge


    Unknown required information, not 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).

  • 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.

    SHA-256 artifact/source checks; no SHA1/MD5 security mechanism identified in Talos runtime.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/provenance.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/backends/adapters.py


    Barely 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]

    Manifest identifiers intentionally schema-coupled to SHA256; no selectable hash agility. Delegated SSH/TLS algorithms negotiate externally. SHOULD may be unmet with provenance-schema migration explanation; do not change manifest identity merely for badge.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/experiment/serialization.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py


    Not 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]

    Executing the current ambience sampler reaches a dependency-owned embedded RANDOM.ORG API credential without a caller credential-file or environment configuration argument. A local replacement reads caller-owned private API key files on every request and verifies rotation without changing source; it remains unmerged. Git credential rotation alone does not clear the sampler finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py


    Unknown required information, not 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]

    Unknown required information, not 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]

    Not 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.

    Executing the current quantum sampler through its distributed Chances0.1.9 dependency reaches urlopen with CERT_NONE and check_hostname=False. A verified stdlib replacement with TLS1.2+, chain/hostname checks and redirect refusal is implemented locally and tested against real loopback TLS servers; it remains unmerged. Other standard dataset/Git transports do not clear this positive finding.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/reducers/sample_reducer.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml


    Unknown required information, not 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]

  • Secure release


    Not 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.

    Latest published v1.4 remains unproven as signed. Merged deploy workflow supports signed provenance on a future authorized wheel/sdist publication. The next branch adds release assets and Sigstore bundles, but workflow code or a local build cannot establish an actual signed release. Await reviewed release execution and consumer verification; do not rewrite old tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/deploy.yml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/docs/Developer/Release-Policy.md
    https://github.com/autonomio/talos/releases/tag/v1.4


    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]

    Current release script creates ordinary tags; latest v1.4 ref is commit object, no signed tag. SUGGESTED can be unmet; do not rewrite historical tags.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/scripts/create_release.py


  • Other security issues


    Not 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.

    Current-source probes reproduce committed-manifest content tampering accepted under an unchanged lineage ID, objective direction sideways accepted, and string false accepted for boolean policy controls. Local regressions reject all of these before caller imports/source hydration, while preserving draft/historical identities; fixes remain unmerged and other constrained-input boundaries still require review.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/store.py
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/talos/yaml/validator.py


    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).

    Project produces interpreted local library/CLI, no account-serving runtime or native build. Describe memory-safe language/delegated platform hardening where applicable; least-privilege CI alone is explicitly not this hardening criterion.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml
    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/SECURITY.md


    Unknown required information, not 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.

 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.

    Master CodeQL run36893895563 succeeded. The Python security analysis workflow is actually merged and executing.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/.github/workflows/pr_checks_codeql.yml
    https://github.com/autonomio/talos/actions/runs/36893895563


  • 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.

    No project-produced code in memory-unsafe language; native framework dependencies monitored separately.

    https://github.com/autonomio/talos/blob/9783406eafd0c9d72d00010aeffb379a534a5349/pyproject.toml



You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/15140/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 Mikko Kotila and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Mikko Kotila.
Entry created on 2026-10-01 16:30:01 UTC, last updated on 2026-10-01 19:11:47 UTC.