Skip to content

Security: stefanoamorelli/sec-edgar-agentkit

Security

SECURITY.md

Tallinn Secure Software Practices for OSS

A security baseline from the OWASP Tallinn Chapter

This project follows the Tallinn Secure Software Practices for OSS, developed to help open source maintainers and contributors build and maintain secure software. It provides a baseline of practical security practices informed by OWASP.

Reporting Security Issues

If you discover a security vulnerability, please report it privately and responsibly.
Do not create a public GitHub issue.

Contact:

We will acknowledge your report within 7 business days and aim to resolve confirmed issues within 90 days or faster, depending on severity. Credit will be given unless anonymity is requested.

Secure Development Practices

Secrets and Credentials

  • Never commit secrets (API keys, passwords, tokens) to the codebase.
  • Use environment variables or secret managers (e.g., Vault, GitHub Actions secrets).
  • Enable secret scanning and use pre-commit hooks to prevent accidental leaks.

Dependencies and Supply Chain

  • Pin dependencies and avoid using unmaintained packages.
  • Use automated tools (e.g., Dependabot, OSV Scanner) to identify known vulnerabilities.
  • Review and verify new dependencies before adding them.
  • Consider generating an SBOM (Software Bill of Materials) for major releases.

Code and Commit Hygiene

  • All changes must go through pull requests with at least one code review.
  • Protect the main branch (e.g., require PRs, reviews, passing CI).
  • Encourage signed commits and signed release tags.
  • Avoid force-pushes and direct commits to protected branches.

CI/CD and Build Security

  • Run builds in isolated, ephemeral environments.
  • Use least-privilege CI tokens and restrict access to secrets.
  • Review third-party CI/CD actions and pin versions or SHAs.
  • Do not deploy unreviewed code to production environments.

Vulnerability Handling Process

Once a vulnerability is confirmed:

  1. It is triaged and, if valid, addressed privately.
  2. A patch is prepared and tested.
  3. A security advisory is published (with CVE if applicable).
  4. A new version is released with the fix.
  5. Acknowledgment is given to the reporter if appropriate.

Contributor Expectations

All contributors are expected to:

  • Follow secure coding practices (e.g., input validation, output encoding).
  • Not introduce known vulnerable dependencies or unsafe constructs.
  • Respect code review and CI checks before merging.
  • Enable 2FA on GitHub or any platform with elevated access.
  • Sign and author your Git commits using a verified identity.

Commit Signing and Authorship

We require contributors to use verified identities in Git commits. Whenever possible, commits should be GPG-signed or signed via GitHub's verified web UI.

This helps ensure:

  • Authenticity – each change can be traced to a real, accountable contributor.
  • Integrity – signed commits cannot be modified without detection.
  • Trust – the project's code history remains verifiable and auditable.

Unsigned or anonymous commits may be flagged and rejected in pull requests, especially for contributors with elevated privileges. See GitHub's documentation on signing commits to get started.

References and Resources

Maintained by: The OWASP Tallinn Chapter
For updates or suggestions, visit: https://owasp.org/www-chapter-tallinn

There aren’t any published security advisories