This policy applies to every repository in the
lakshmanachari-panuganti organisation
unless a repository publishes its own SECURITY.md.
Please do not open a public issue for a security problem. A public issue tells everyone about the weakness before there is a fix.
Use GitHub Private Vulnerability Reporting, which is enabled on all of our repositories:
- Open the repository on GitHub
- Go to the Security tab
- Click Report a vulnerability
This creates a private channel visible only to the maintainers.
If you cannot use that form, email studio@srilatha.art with SECURITY in the
subject line.
The more of this you can provide, the faster we can confirm and fix it:
- The affected repository, and the version, tag or commit
- What kind of issue it is (for example: injection, authentication bypass, privilege escalation, exposed secret, supply-chain)
- Step-by-step instructions to reproduce it
- Proof-of-concept code, if you have it
- What an attacker could achieve — the impact, in practical terms
- Any suggested fix or mitigation
| Stage | Our target |
|---|---|
| We acknowledge your report | within 3 business days |
| We confirm or dispute the finding | within 10 business days |
| We ship a fix for a confirmed high-severity issue | within 30 days |
| We publish an advisory | after the fix is released |
These are targets, not contractual guarantees — this organisation is maintained by one person. We will tell you if something is taking longer, rather than going quiet.
We follow coordinated disclosure. Please give us a reasonable opportunity to fix the issue before making it public. We will:
- Keep you informed as we work on it
- Credit you in the advisory, unless you would rather stay anonymous
- Publish a GitHub Security Advisory once a fix is available
We will not pursue legal action against researchers who act in good faith, stay within the scope below, and give us a chance to respond before publishing.
In scope — anything in the repositories of this organisation:
- Application and library source code
- GitHub Actions workflows and build scripts
- Infrastructure-as-code and deployment configuration
- Dependency and supply-chain issues that we can act on
- Accidentally committed secrets or credentials
Out of scope:
- Findings in third-party services we merely consume (report those to the vendor)
- Automated scanner output with no demonstrated impact
- Denial of service, volumetric or resource-exhaustion testing
- Social engineering, phishing, or physical access
- Missing hardening headers with no exploitable consequence
- Anything requiring an already-compromised machine or account
Please do not access, modify or exfiltrate data that is not yours, degrade service for real users, or test against production payment flows. If you need a test environment to demonstrate something, ask us first.
Only the latest release of each package or deployed application receives security fixes. For PowerShell modules published to the PowerShell Gallery, that means the most recent published version.
Secret scanning and push protection are enabled across the organisation. If you discover a credential exposed in any repository or in its git history, treat it as a high-severity report and tell us immediately — do not test how far it gets you.
- Private vulnerability reporting is enabled on every repository
- Dependabot alerts and automated security updates are enabled
- Branch protection requires review before anything reaches a default branch
- Secrets are stored in GitHub Actions secrets or Azure Key Vault, never in source
Thank you for helping keep this project and its users safe.