Security is how we build, not a page we publish
We sell security services, so we hold our own systems to the standard we audit others against. This is our public security posture — disclosure policy, engineering practices, and how to reach us.
Responsible disclosure
If you find a vulnerability in any StellerSight system or product, report it to admin@stellersight.com with "Security" in the subject. We commit to acknowledging reports within 48 hours, keeping you informed while we fix, and never taking legal action against good-faith research. Please give us reasonable time to remediate before public disclosure.
security.txt
We publish a machine-readable security contact per RFC 9116 at /.well-known/security.txt. Scanners, researchers, and automated tooling can always find the right channel — no guessing, no dead ends.
How our own systems are run
TLS everywhere with HSTS preload, strict Content-Security-Policy, containerised workloads with least-privilege networking, fail2ban and rate limiting at the edge, automated patching, and 90-day audit log retention on administrative surfaces. The practices we recommend in audits are the ones running here.
Scope
In scope: stellersight.com and its subdomains, and StellerSight-operated product platforms. Out of scope: denial-of-service testing, social engineering of our staff or clients, and third-party services we don't control. When in doubt, ask first — we respond fast.
Practices we build into every engagement
Zero-trust defaults
Least privilege, network segmentation, and no implicit trust between services.
Secure SDLC
Threat modelling at design time, dependency scanning, and review gates in CI/CD.
Hardened delivery
Security headers, TLS configuration, secrets management, and audited deploy pipelines.
Assume breach
Logging, monitoring, and incident-response runbooks in place before go-live, not after.
Need this discipline on your systems?
VAPT, security audits, GRC programmes, and incident response — delivered by the team that runs its own infrastructure this way.