Security fixes are applied to the maintained code line of matiz-studio-creative/sri-toolkit.

Public usage documentation is available at https://sri-toolkit.matizstudiocreative.com. Do not use the public documentation site, public issues or pull requests to disclose vulnerabilities.

The project is tested in CI with PHP 8.2, 8.3, 8.4 and 8.5. If you are using an older PHP runtime, upgrade before reporting an issue unless the vulnerability is also reproducible on a supported runtime.

Please do not disclose security vulnerabilities in public issues, pull requests, discussions or social channels.

Report vulnerabilities privately using one of these channels:

1. Open a private GitHub Security Advisory for the repository: https://github.com/Sebas-DV/sri-toolkit/security/advisories
2. If GitHub advisories are not available, email the maintainer listed in composer.json.

Include as much of the following as possible:

• Affected package version, commit hash or branch.
• PHP version and enabled extensions.
• Minimal proof of concept or reproduction steps.
• Expected impact and whether credentials, certificates, signed XML, SOAP requests or SRI responses are exposed.
• Any relevant stack traces, logs or payloads with secrets removed.

You should receive an initial response within 7 days. Confirmed vulnerabilities will be handled privately until a fix, mitigation or coordinated disclosure plan is available.

The security-sensitive parts of this library include:

• PKCS#12 certificate loading and password handling.
• Private key use through OpenSSL.
• XML loading, canonicalization and XAdES-BES signature generation.
• SOAP communication with SRI reception and authorization web services.
• Parsing of SRI responses and propagation of error messages.
• Composer dependencies and CI configuration.

Examples of vulnerabilities that are in scope:

• Private key, certificate password, signed XML or taxpayer data exposure.
• XML parser behavior that enables XXE, entity expansion, signature wrapping or unsafe namespace handling.
• Incorrect signing behavior that can produce tamperable or misleading signed documents.
• SOAP configuration that weakens TLS verification or leaks request/response contents.
• Dependency vulnerabilities that affect runtime code.

Examples generally out of scope:

• SRI service downtime, latency or external availability issues.
• Misconfigured applications that store certificate files in public web roots.
• Public disclosure of test certificates generated by the test suite.
• Vulnerabilities that require modifying local vendor code or disabling PHP/OpenSSL security controls.

This package handles fiscal documents and digital certificates. Applications using it should apply these controls:

• Store .p12 / .pfx certificates outside the web root and outside the repository.
• Keep certificate passwords in a secret manager or protected environment variable, not in source code, fixtures or logs.
• Restrict certificate file permissions to the application user that performs signing.
• Rotate certificates and passwords if they are exposed in logs, CI artifacts, issue reports or chat systems.
• Avoid logging signed XML, SOAP requests, SOAP responses and lastResponse() output unless the data has been reviewed and redacted.
• For production SOAP clients, consider overriding SenderConfig::$soapOptions to disable tracing if request/response inspection is not required, for example trace => 0.
• Use only the official SRI WSDL endpoints unless you explicitly control and trust a replacement endpoint.
• Keep PHP, OpenSSL, SOAP, DOM and libxml extensions patched through your operating system or container image.

The library uses SHA-1 based XMLDSig/XAdES-BES algorithms because they are part of the SRI-compatible signing format implemented here. Do not treat this implementation as a general-purpose modern signing primitive for unrelated protocols.

For non-sensitive setup and usage details, see the public documentation at https://sri-toolkit.matizstudiocreative.com.

Before releasing security-sensitive changes, run the local quality suite:

composer analyze
composer audit

At minimum, security patches should pass:

composer test
composer stan
composer cs:test
composer rector:test

If a vulnerability requires a dependency update, commit both composer.json and composer.lock.

After a vulnerability is confirmed, maintainers should:

1. Reproduce and assess severity.
2. Prepare a fix on a private branch or advisory fork when appropriate.
3. Add regression tests where feasible.
4. Release a patched version and document the affected versions.
5. Publish the advisory after users have a reasonable upgrade path.

Credit will be given to reporters who want attribution, unless they request anonymity.