Skip to content

BestPracticesChecklist.md

Latest commit

 

History

History
265 lines (172 loc) · 14.8 KB

BestPracticesChecklist.md

File metadata and controls

265 lines (172 loc) · 14.8 KB
Raw

AOSSIE Best Practices Checklist

Criteria adapted from the OpenSSF Best Practices Badge (MIT / CC BY 3.0) by OpenSSF contributors. Modified for AOSSIE multi-repo template use.

Purpose: Covers OpenSSF Best Practices criteria that are NOT auto-detected by OpenSSF Scorecard. Scorecard already handles: License, SAST tools, CI tests, Security Policy file, Branch Protection, Pinned Dependencies, Signed Releases, Maintained status, and Known Vulnerabilities.

How to use:

  1. Fill in checkboxes below — tick [x] for Met, leave [ ] for Unmet, use [~] for N/A
  2. Add a brief note or URL after each item as evidence
  3. Run the checklist-score workflow to update the badge automatically

Legend:

  • 🔴 MUST — Required for passing
  • 🟡 SHOULD — Required unless documented rationale given
  • 🔵 SUGGESTED — Optional but recommended
  • ⚪ N/A — Mark [~] if not applicable, add justification

Score Summary

Category Met Total Status
Basics 8 8 ✅
Change Control 6 6 ✅
Reporting 8 8 ✅
Quality 11 11 ✅
Security 9 9 ✅
Analysis 6 7 🟡
Total 48 49 98%

🏗️ Basics

Project Website & Documentation

Other Basics

  • 🔴 discussion — Project has a searchable, URL-addressable discussion mechanism (GitHub Issues, Discord with archive, mailing list, etc.) that doesn't require proprietary client software.

  • 🟡 english — Documentation is provided in English and English bug reports/comments are accepted.

    • Note: All project documentation, code comments, GitHub issue templates, and commit messages are in English.

🔄 Change Control

Version Control

Version Numbering

Release Notes

🐛 Reporting

Bug Reporting

  • 🔴 report_process — A bug-reporting process exists (e.g., GitHub Issues link in README).

  • 🟡 report_tracker — An issue tracker (e.g., GitHub Issues) is used to track individual bugs.

  • 🔴 report_responses — A majority of bug reports submitted in the last 2–12 months have been acknowledged (response ≠ fix).

    • Self-certification note: Maintainers actively monitor and respond to all bug reports submitted via GitHub Issues and Discord.

  • 🟡 enhancement_responses — More than 50% of enhancement requests in the last 2–12 months have received a response.

    • Self-certification note: Over 50% of enhancement requests receive maintainer feedback and triaging.

  • 🔴 report_archive — Reports and responses are publicly archived and searchable (GitHub Issues satisfies this).

Vulnerability Reporting

✅ Quality

Build System

  • [~] 🔴 build — If the project requires building, a working build system exists that can auto-rebuild from source.

    • Justification: Interpreted language (Python 3.10+); no compilation or build step required.

  • 🔵 build_common_tools — Common build tools are used (npm, pip, cargo, make, gradle, etc.). (SUGGESTED)

  • 🟡 build_floss_tools — The project can be built using only FLOSS tools.

    • Note: Built and executed using FLOSS tools (Python, pip, venv, and Git).

Automated Testing

  • 🔵 test_invocation — The test suite can be invoked in a standard way for the language (e.g., npm test, pytest, cargo test). (SUGGESTED)

  • 🔵 test_most — The test suite covers most code branches, input fields, and functionality. (SUGGESTED)

    • Estimated coverage %: ~75% (covers repository routing in repo_router.py, bot event loops in bot.py, subtree updates in scripts/update_subtrees.py, and gap logging).

New Functionality Testing Policy

Linting / Warning Flags

  • 🔴 warnings — At least one linter or compiler warning flag is enabled (ESLint, Pylint, clippy, golangci-lint, Slither for Solidity, etc.).

    • Tool used: pre-commit hooks (trailing-whitespace, check-yaml, check-json, check-toml, detect-secrets), Danger JS (dangerfile.js), and CodeQL SAST.

  • 🔴 warnings_fixed — Warnings from the linter are addressed (not suppressed without reason).

    • Note: All linter warnings from pre-commit hooks, Danger JS, and CodeQL analysis are addressed before merging.

  • 🔵 warnings_strict — Project uses maximum strictness in linter config where practical. (SUGGESTED)

    • Note: Strictly enforces file hygiene, secret scanning, and static analysis via pre-commit and Danger CI checks.

🔐 Security

Secure Development Knowledge

  • 🔴 know_secure_design — At least one primary developer knows how to design secure software (familiar with OWASP, threat modeling, secure-by-default principles).

    • Self-certification note: Maintainers follow OWASP principles, local-first data isolation, and least-privilege security design.

  • 🔴 know_common_errors — At least one primary developer knows common vulnerability types for this software's category and how to mitigate them (e.g., injection, XSS, reentrancy for Solidity, prompt injection for AI).

    • Self-certification note: Maintainers are trained in AI prompt injection risks, sensitive environment variable handling (.env), and secret scanning.

Cryptography (mark N/A if project does not handle cryptography)

  • [~] 🔴 crypto_published — Only publicly reviewed cryptographic protocols/algorithms are used by default.

    • Justification: Application uses standard TLS/HTTPS provided by discord.py and httpx; no custom cryptographic protocols implemented.

  • [~] 🟡 crypto_call — Project calls an established crypto library rather than reimplementing crypto functions.

    • Justification: Relies on underlying Python standard library and TLS network stack.

  • [~] 🔴 crypto_working — No broken algorithms (MD4, MD5, single DES, RC4, Dual_EC_DRBG) used unless required for interoperability (must be documented).

    • Justification: No broken or deprecated algorithms used.

  • [~] 🔴 crypto_keylength — Key lengths meet NIST 2030 minimums by default.

    • Justification: Managed by standard SSL/TLS protocol implementations.

  • [~] 🔴 crypto_password_storage — Passwords for external users are stored as iterated salted hashes (Argon2id, bcrypt, scrypt, PBKDF2).

    • Justification: Skill Bot does not collect, store, or manage user passwords.

  • [~] 🔴 crypto_random — Cryptographic keys and nonces are generated using a CSPRNG; insecure generators (Math.random, rand()) are NOT used for security purposes.

    • Justification: Application does not generate cryptographic keys or nonces.

  • 🟡 delivery_unsigned — Cryptographic hashes are NOT retrieved over plain HTTP without a signature check.

    • Note: All packages, models, and dependencies are retrieved strictly over HTTPS.

🔬 Analysis

Static Code Analysis

  • 🔴 static_analysis_fixed — All medium+ severity vulnerabilities found by static analysis are fixed in a timely manner after confirmation.

    • Note: CodeQL, Gitleaks, and OSV-Scanner findings are fixed immediately upon detection.

  • 🔵 static_analysis_common_vulnerabilities — The static analysis tool includes checks for common vulnerabilities in the language/environment (e.g., eslint-plugin-security, bandit, Slither). (SUGGESTED)

    • Tool + ruleset: CodeQL (python-security-and-quality), Gitleaks secret scanner, and OSV-Scanner.

  • 🔵 static_analysis_often — Static analysis runs on every commit or at least daily (CI integration). (SUGGESTED)

Dynamic Code Analysis

  • 🔵 dynamic_analysis — At least one dynamic analysis tool is applied before major releases (fuzzer, web app scanner like OWASP ZAP, etc.). (SUGGESTED)

    • Tool used: None — Justification: No security-focused dynamic analysis tool (such as fuzzing, DAST, or web application scanning) is integrated into the project.

  • [~] 🔵 dynamic_analysis_enable_assertions — Dynamic analysis / testing runs with assertions enabled (not just production mode). (SUGGESTED)

    • Note: [~] N/A — Justification: No security-focused dynamic analysis tool in use.

  • [~] 🔴 dynamic_analysis_fixed — Medium+ severity vulnerabilities found by dynamic analysis are fixed in a timely manner.

    • Note: [~] N/A — Justification: No security-focused dynamic analysis tool in use.

  • [~] 🔵 dynamic_analysis_unsafe — If the project uses memory-unsafe languages (C/C++), memory safety tools (Valgrind, AddressSanitizer) are used. (SUGGESTED)

    • Note: [~] N/A — Justification: Project is developed in Python, a memory-safe language.

📎 Project-Specific Notes

Add domain-specific notes here for Web3, Full-Stack, or AI projects.

Web3 / Solidity Notes

  • Scorecard does not audit Solidity-specific security. Use Slither for static_analysis and warnings criteria.
  • For crypto_* criteria, document which cryptographic primitives your contracts rely on (e.g., ECDSA in EVM is standard).
  • Smart contract audit reports count as evidence for know_secure_design.

Full-Stack / Next.js Notes

  • For crypto_password_storage: document which auth library handles hashing (e.g., NextAuth + bcrypt).
  • For dynamic_analysis: OWASP ZAP can be run as a GitHub Action.

AI / LLM Notes

  • For know_common_errors: Maintainers are aware of prompt injection, system context leaking, and validation of local LLM responses (Ollama).
  • For dynamic_analysis: Functional test suites (scripts/test_bot_routing.py) validate bot routing and response logic, but do not replace security-focused dynamic analysis (such as fuzzing or web scanning).

This checklist complements OpenSSF Scorecard (auto-detected checks) and is inspired by the OpenSSF Best Practices Badge passing criteria.