This repository is a maintained fork of the archived fossteams/teams-cli project. Security issues should be reported privately and must not include Teams JWTs, authentication headers, cookies, or private message data.

Preferred path:

1. Use GitHub private vulnerability reporting on this fork if it is available.
2. Otherwise contact the maintainer account directly on GitHub before opening a public issue.

Do not open a public issue for:

• token leakage or token-handling flaws
• authentication bypasses
• log redaction failures
• release artifact or CI supply-chain concerns
• anything that would require posting secrets or private Teams data

Share only the minimum details needed to reproduce and triage the issue:

• affected version, tag, or commit
• operating system and architecture
• whether the issue affects runtime behavior, logging, release artifacts, or CI
• sanitized reproduction steps
• impact and expected severity
• any proposed mitigation if you already have one

If logs are needed, redact or replace:

• JWTs and bearer tokens
• Authorization or Authentication headers
• cookies
• tenant-specific secrets or confidential message content

• Initial acknowledgement: within 5 business days
• Triage update: within 14 calendar days
• Fix timeline: depends on severity and reproducibility

The most security-sensitive areas in this fork are:

• token discovery and export
• request authentication and retry behavior
• local log storage and redaction
• release artifacts and CI workflows
• repository governance and protected-branch policy

This maintained fork uses layered preventive controls in addition to manual review:

• protected dev and main branches
• CODEOWNERS coverage for repository-critical paths
• required CI status checks before normal merges
• required signed commits on protected branches
• CodeQL analysis for Go code
• dependency review on pull requests
• secret scanning in CI
• protected release environment approval before publication
• release smoke tests, a bundled SPDX SBOM archive, a signed checksum file, and GitHub provenance attestations for published release artifacts

These checks reduce risk, but they do not replace careful review of token handling, request authentication, or release artifacts.

Consumers should prefer release assets that can be validated through all of the following:

• checksum verification
• cosign bundle verification for the published checksum file
• GitHub attestation verification for build provenance
• SBOM review using the bundled release SBOM archive

If any of these materials are missing or fail validation, treat the release as suspect until it is reviewed.

Please wait for a fix or an agreed disclosure date before publishing details. If a report turns out to be non-sensitive hardening work, it can be converted into a normal issue after the risk is understood.