The OSIRIS JSON Security Policy

This document explains how to report security issues in the OSIRIS JSON producers project and how maintainers handle coordinated disclosure.

Please do not open a public GitHub issue, discussion, or pull request for a suspected vulnerability.

Scope

This policy covers the go.osirisjson.org/producers Go module, including:

• the producer SDK under pkg/sdk
• test and validation support code used by producers
• all producer packages under the module
• command-line tools and CLI binaries built from this repository
• release artifacts published from tagged versions of this module

The policy applies to vulnerabilities in project code, build and release artifacts, credential handling, input parsing, dependency usage, and behavior that could compromise confidentiality, integrity, or availability for users of the SDK or CLI tools.

Supported versions

Only the latest tagged release receives security fixes.

Users should upgrade as soon as possible to the latest patched release when a security fix is published.

Private reporting channels

Use one of the following private channels to report a vulnerability:

1. GitHub private security advisory, preferred
   Open a private report through GitHub Security Advisories:
   https://github.com/osirisjson/osiris-producers/security/advisories/new

2. Email
   Send the report to [email protected].
   If the report contains highly sensitive technical details, credentials, private topology data, or exploit material, please minimize included secrets and encrypt the message if a maintainer public key is available you can refer to the maintainer dedicated page.

If you do not receive an acknowledgement within 3 business days, follow up by email at [email protected].

What to include

A useful report should include:

• a clear description of the vulnerability
• the affected package, command, binary, or release version
• the expected and actual behavior
• step-by-step reproduction instructions or a minimal proof of concept
• relevant input files, payloads, logs, stack traces, or command output
• the potential impact on confidentiality, integrity, or availability
• any known mitigations or workarounds
• whether you would like public credit, private credit, or no credit

Please avoid sending real production credentials, private keys, customer data, or sensitive infrastructure exports unless maintainers explicitly request a sanitized sample through a private channel.

Coordinated disclosure process

OSIRIS JSON follows coordinated disclosure:

1. The reporter submits the vulnerability through a private channel.
2. Maintainers acknowledge receipt and assign an initial severity.
3. Maintainers reproduce and validate the issue.
4. Maintainers prepare a fix, mitigation, or documented rejection if the report is not a vulnerability.
5. A patched release is published when required.
6. A GitHub Security Advisory is published when appropriate, with CVE coordination if applicable.
7. The reporter is credited unless they request anonymity.

Maintainers ask reporters to keep vulnerability details private until a fix, mitigation, or advisory is available.

Response targets

Critical issues that may expose credentials, permit remote code execution, compromise release artifacts, or cause unsafe behavior in common producer workflows are prioritized immediately.

Security monitoring

The project is monitored with SonarCloud/SonarQube analysis. Security-related measures for the producers project are available at SonarQube Report website.

Static analysis is a supporting control, not a replacement for manual review, vulnerability reporting, dependency scanning, or coordinated disclosure.

Security expectations for contributors

Contributors should follow these requirements when changing SDK, producer, CLI, authentication, networking, parsing, or release code.

Credentials and secrets

• Never commit credentials, API keys, tokens, certificates, private keys, or real infrastructure exports.
• Use environment variables, files with restricted permissions, or external secret stores for runtime credentials.
• Producers that accept passwords interactively must disable terminal echo.
• Do not log, print, serialize, or include credentials in error messages.

Network and TLS

• HTTP clients must enforce TLS 1.2 or newer.
• Do not force InsecureSkipVerify: true in production paths.
• If insecure TLS is necessary for a diagnostic workflow, it must require an explicit user option and print a clear warning.
• Set reasonable timeouts on HTTP clients and transports.
• Validate URLs, hostnames, and user-controlled connection settings before use.

Input Validation

• Treat vendor API responses, exported files, and user-provided configuration as untrusted input.
• Validate and sanitize file paths, identifiers, labels, log fields, and payloads before use.
• Avoid path traversal, command injection, log injection, and unsafe deserialization patterns.
• Prefer SDK normalization helpers for user-facing identifiers where applicable.

Dependencies

• Keep dependencies minimal, especially in SDK code.
• Pin and review dependency updates in go.mod and go.sum.
• Run go mod verify in CI where practical.
• Monitor Go dependencies with vulnerability tooling such as govulncheck.

Code Review and Release

• Security-sensitive changes require maintainer review before merge.
• Release binaries should be built from tagged commits.
• Build processes should avoid embedding local paths, credentials, or environment-specific secrets.
• Security fixes should include tests or validation steps when practical.

Out of Scope

The following are normally out of scope:

• vulnerabilities that only affect unsupported older releases
• issues in Go itself or third-party dependencies, unless the project uses them in an unsafe way
• denial of service caused solely by intentionally huge input where callers are expected to enforce size limits
• social engineering, phishing, or physical attacks against maintainers
• reports based only on missing security headers for documentation or static pages unrelated to the module
• theoretical issues without a credible attack path or reproduction detail

Maintainers may still accept hardening suggestions for out-of-scope topics, but they may not be handled as security advisories.