edgar-sec

The project maintains older versions of the product and provides an upgrade path to newer versions. The CHANGELOG.md file (https://github.com/nikhilxsunder/edgar-sec/blob/main/CHANGELOG.md) documents all changes, including new features, bug fixes, and deprecated functionality, to help users understand what has changed between versions.

For major updates that introduce breaking changes, the project follows Semantic Versioning and includes detailed instructions in the CHANGELOG.md to guide users through the upgrade process. This ensures users can either continue using older versions or transition smoothly to newer ones.

https://github.com/nikhilxsunder/edgar-sec/issues

The project has not resolved any reported vulnerabilities in the last 12 months. Therefore, this criterion is marked as Not Applicable (N/A).

For future reference, the project documents vulnerability reports and credits reporters in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The project has a documented process for responding to vulnerability reports in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The process includes the following steps:

Reporting: Vulnerabilities must be reported via email to nsunder724@gmail.com, not through public GitHub issues.
Acknowledgment: The project team will acknowledge receipt of the report within 48 hours.
Verification: The team will verify the vulnerability and assess its impact.
Remediation: A fix will be developed and tested.
Disclosure: The team will coordinate with the reporter on the disclosure timeline and credit the reporter unless anonymity is requested.
This ensures a clear and structured approach to handling vulnerabilities.

The project identifies and enforces coding standards in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

The project adheres to the following coding style guides:

PEP 8: The official Python style guide for code readability and consistency.
PEP 257: For docstring conventions, including parameter descriptions, return values, and examples.
Type Hints (PEP 484): All functions must include type annotations for parameters and return values.
The CONTRIBUTING.md file also specifies the use of tools like pylint, mypy, and bandit to enforce these standards and ensure compliance. Contributors are required to run these tools before submitting pull requests.

The project automatically enforces its selected coding styles using the following tools, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

Pylint: Enforces PEP 8 compliance and general code quality. A minimum score of 9.0+ is required for all code.
Mypy: Enforces type checking to ensure compliance with PEP 484.
Bandit: Performs security-focused static analysis to identify common security issues.
These tools are integrated into the development workflow via pre-commit hooks and GitHub Actions workflows. All pull requests are automatically checked for compliance, and any exceptions must be explicitly documented in the code with comments explaining the rationale.

The project does not generate native binaries, as it is a Python library. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not involve a build or installation system that generates native binaries. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not use a build system that involves recursive builds or subdirectory dependencies. Therefore, this criterion is marked as Not Applicable (N/A).

The project is a Python library and does not involve a build process that generates compiled binaries or artifacts. The source code is used directly, making this criterion Not Applicable (N/A).

The project provides an easy way to install and uninstall the software using commonly-used conventions:

Using pip: The software can be installed and uninstalled via the Python package manager pip, which is widely used in the Python ecosystem.

Installation: pip install edgar-sec Uninstallation: pip uninstall edgar-sec Using conda: The software is available on Conda-Forge, allowing installation and uninstallation via the conda package manager.

Installation: conda install -c conda-forge edgar-sec Uninstallation: conda remove edgar-sec Detailed installation instructions are documented in the README.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/README.md and the installation.rst file in the documentation: https://nikhilxsunder.github.io/edgar-sec/installation/.

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]

The project provides a quick and straightforward way for developers to install all necessary dependencies and set up the development environment using commonly-used conventions. This is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

Development Setup:
Using Poetry:

Clone the repository: git clone https://github.com/nikhilxsunder/edgar-sec.git
Navigate to the project directory: cd edgar-sec
Install dependencies: poetry install
Run tests: poetry run pytest
Using Conda:

Clone the repository: git clone https://github.com/nikhilxsunder/edgar-sec.git
Navigate to the project directory: cd edgar-sec
Create a Conda environment: conda create -n edgar-sec-dev python=3.10
Activate the environment: conda activate edgar-sec-dev
Install dependencies: pip install -e ".[dev,types]"
Run tests: pytest
These steps ensure that developers can quickly set up the environment and run tests to start contributing to the project.

The project lists its external dependencies in a computer-processable way using pyproject.toml and poetry.lock files. These files are compatible with the Poetry package manager and specify all required dependencies, including their versions and groups (e.g., main, dev).

The pyproject.toml file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/pyproject.toml.
The poetry.lock file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/poetry.lock.

The project monitors its external dependencies for known vulnerabilities using automated tools and processes:

GitHub Dependabot: Automatically scans dependencies for vulnerabilities and creates pull requests to update them when issues are detected. CodeQL: Performs security analysis on the codebase, including dependency vulnerabilities. Poetry: Dependency management ensures that only compatible and secure versions of packages are installed. These tools are integrated into the project's workflows and run regularly to ensure that vulnerabilities are detected and addressed promptly. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The project meets this criterion by using standard Python package management systems, such as pip and poetry, to manage external dependencies. All reused components are listed in the pyproject.toml and poetry.lock files, making it easy to identify and update them. These files ensure that dependencies are managed in a centralized and consistent manner.

Additionally, the project uses GitHub Dependabot to automatically monitor and suggest updates for dependencies when vulnerabilities or new versions are detected. For more details, see the pyproject.toml file: https://github.com/nikhilxsunder/edgar-sec/blob/main/pyproject.toml.

The project avoids using deprecated or obsolete functions and APIs by adhering to modern Python standards and regularly updating its dependencies. The project uses tools like pylint, mypy, and bandit to identify deprecated or unsafe code patterns. Additionally, dependency updates are managed through poetry and monitored using GitHub Dependabot to ensure compatibility with the latest versions of libraries.

For more details, see the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

The project applies an automated test suite on each check-in to the shared repository for the main branch. This is implemented using GitHub Actions workflows, which run the test suite automatically on every push and pull request. The test suite uses pytest and generates a report on test success or failure.

For more details, see the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md and the GitHub Actions workflows in the repository: https://github.com/nikhilxsunder/edgar-sec/actions.

The project includes regression tests for bugs fixed within the last six months as part of its automated test suite. All new functionality and bug fixes are required to have corresponding tests, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

Additionally, the CHANGELOG.md file (https://github.com/nikhilxsunder/edgar-sec/blob/main/CHANGELOG.md) tracks bug fixes, and the associated tests are added to the tests directory to ensure coverage and prevent regressions.

The project currently has an overall test coverage of 100%, as documented in the TEST_COVERAGE.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/TEST_COVERAGE.md.

The project has a formal written policy requiring that tests for all new functionality be added to the automated test suite. This policy is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md.

The policy states:

All new functionality must include appropriate tests in the automated test suite.
Tests should cover both success and error conditions, including edge cases.
Pull requests without adequate test coverage will not be merged.
This ensures that the test suite remains comprehensive and up-to-date as the project evolves.

https://github.com/nikhilxsunder/edgar-sec/blob/main/CONTRIBUTING.md

Yes, the project uses maximum strictness with warnings where practical. We enforce a high pylint score (9.0+), use strict type checking in mypy (with most error flags enabled), and run thorough security checks with bandit. These strict settings are enforced in CI for all PRs, and our CONTRIBUTING.md document explicitly requires all new code to pass these strict checks.

The project implements secure design principles as outlined in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md. These principles include:

Fail-Safe Defaults: The API client enforces secure defaults, such as HTTPS for all communications and strict parameter validation.
Complete Mediation: All API requests verify authentication and authorization, ensuring no bypassable access points.
Economy of Mechanism: The codebase is modular and avoids unnecessary complexity, focusing on simplicity and maintainability.
Separation of Privilege: The project recommends storing API keys in environment variables or secure vaults, separate from application code.
Open Design: The project is open source, relying on proper key management and secure practices rather than obscurity.
These principles ensure that the software is secure by design and adheres to best practices for secure development.

The project does not depend on cryptographic algorithms or modes with known serious weaknesses. It uses secure cryptographic libraries provided by Python's standard library or well-maintained third-party libraries, such as cryptography or hashlib, which default to secure algorithms like SHA-256 or AES-GCM.

For more details on the project's security practices, see the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The software produced by the project communicates with the FRED API exclusively over HTTPS, which uses TLS 1.2 or later for secure network communications. Insecure protocols such as HTTP are not supported. This ensures that all network communications are encrypted and secure by default.

For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The software produced by the project communicates with the EDGAR API exclusively over HTTPS, which uses TLS 1.2 or later for secure communication. Therefore, this criterion is met. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The project cryptographically signs its releases intended for widespread use. All releases are signed with a GPG key, and the public key is made available for users to verify the signatures. The process for obtaining the public signing key and verifying signatures is documented in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

To verify a release:

Download the public GPG key from: https://raw.githubusercontent.com/nikhilxsunder/edgar-sec/main/edgar_sec_public_key.asc.
Import the key: gpg --import edgar_sec_public_key.asc.
Verify the release signature using: gpg --verify <release>.asc <release>.
The private key used for signing is securely stored and is not present on public distribution sites.

The project cryptographically signs important version tags using GPG. Each release is signed and can be verified by users to ensure authenticity. The process for verifying signed tags is documented in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

To verify a signed tag:

Download the public GPG key: https://raw.githubusercontent.com/nikhilxsunder/edgar-sec/main/edgar_sec_public_key.asc. Import the key: gpg --import edgar_sec_public_key.asc. Verify the tag: git tag -v . This ensures that all major, minor, and vulnerability-fix releases are securely signed and verifiable.

The Edgar-SEC project validates all inputs from potentially untrusted sources using allowlists and strict format checks. For example, CIKs and accession numbers are checked for correct length and syntax before processing. Numeric inputs are validated to ensure they fall within expected ranges, and text inputs are checked for valid encoding and patterns. Invalid inputs are rejected with clear error messages. This approach helps prevent malformed data and ensures robust, secure handling of user-provided information.

The project incorporates hardening mechanisms to reduce the likelihood of software defects resulting in security vulnerabilities:

HTTP Security: The project enforces HTTPS for all API communications, ensuring secure data transmission. Static Analysis: Tools like bandit are used to identify and mitigate common security issues in Python code. Dependency Management: Regular updates and dependency scanning with GitHub Dependabot ensure that third-party libraries are secure. Type Safety: The use of Python type hints and static type checking with mypy helps prevent undefined behavior. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The project provides an assurance case that justifies why its security requirements are met in the SECURITY.md file: https://github.com/nikhilxsunder/edgar-sec/blob/main/SECURITY.md.

The assurance case includes:

Threat Model: The SECURITY.md file identifies potential threats, such as insecure API key handling, injection in API parameters, and certificate verification bypass. Trust Boundaries: The document defines trust boundaries, such as the separation of API keys from application code and the use of HTTPS for all communications. Secure Design Principles: The project follows secure design principles, including fail-safe defaults, complete mediation, and separation of privilege, as outlined in the Security Design Principles section. Countering Common Weaknesses: The project addresses common implementation security weaknesses, such as dependency vulnerabilities, insecure deserialization, and regular expression denial of service (ReDoS), through dependency scanning, strict input validation, and careful design. This comprehensive assurance case demonstrates the project's commitment to meeting its security requirements.

Yes, the project uses Bandit, a security-focused static analysis tool specifically designed to detect common vulnerabilities in Python code. Bandit is configured in our development environment, integrated into our pre-commit hooks, and runs automatically in our CI/CD pipeline. This helps us identify security issues early in the development process, as documented in our CONTRIBUTING.md file.

Python is memory safe.