SiteShadow
Request access Login
Menu
Login Home Library Proofs Docs Pricing Blog Privacy
Request access

Docs

Standards and best practices, built into the product.

SiteShadow turns security and engineering standards into automated guardrails. The goal is simple: ship code that is hardened by default, without slowing developers down.

Testing category: SiteShadow is SAST (static analysis) — it inspects code and configuration, rather than probing a running application (DAST).

Audit-ready: SOC 2 Type II and ISO 27001

Static-analysis security testing is a named requirement in SOC 2 (CC7.1, CC8.1) and ISO 27001 (A.8.28, A.8.29). SiteShadow does that job, in CI, on every commit. Coverage published here; the methodology lives in the detection credibility matrix.

“SAST is the named requirement. SiteShadow is the SAST. The mapping is published, the scope is benchmarked, the artifacts are exportable.”

  • SOC 2 Type II — Trust Services Criteria. SiteShadow generates the SAST artifacts SOC 2 examiners cite for CC7.1 (system monitoring and vulnerability identification) and CC8.1 (change management with security testing). Every scan is a timestamped, exportable artifact.
  • ISO/IEC 27001:2022 — Annex A. SiteShadow covers A.8.28 (secure coding) and A.8.29 (security testing in development and acceptance), in-product, on every commit. These are the two named Annex A controls that ask for a SAST tool.
  • Scope that survives auditor scrutiny. 190 CWEs, 100% OWASP Top 10 2025 coverage, ten languages, 2,000+ checks. Coverage is published, benchmarked, and reproducible, not asserted.

SiteShadow is the SAST inside your compliance program, not the program itself. SiteShadow does not write your policies, does not run your access reviews, and does not replace your GRC platform. SiteShadow is not a certification and is not a SOC 2 or ISO 27001 attestation in itself; it is the SAST evidence those frameworks require.

Security-focused standards

Foundational references that drive secure coding guidance and scanning claims.

  • OWASP Secure Coding Practices: input validation, output encoding, authentication and password management, session management, access control, cryptographic practices, error handling and logging, data protection, communication security, configuration, database security, file and memory management, and general coding practices.
  • OWASP Top 10 and Cheat Sheets: language-agnostic guidance on common web risks (injection, XSS, authentication, and more) and how to avoid them in code.
  • CWE (MITRE Common Weakness Enumeration): a catalog of specific weaknesses like buffer overflows, injection, and insecure path handling. SiteShadow can be positioned as CWE-aware or CWE-informed.
  • AI/LLM security (emerging): as teams adopt AI-assisted development and agent workflows, the threat model changes. SiteShadow is expanding guardrails for prompt boundaries, tool safety, and abuse resistance — without exposing internal detection logic.

“SiteShadow bakes in OWASP-aligned secure coding checks and CWE-driven weakness detection, so your team ships code that is hardened by default.”

Reference links: OWASP Secure Coding Practices OWASP Top 10 CWE (MITRE)

General engineering best practices

Security is stronger when the engineering fundamentals are non-negotiable.

  • Code quality and engineering practices: version control, continuous integration, automated tests, code reviews, pair programming, style guides, and clean code principles (KISS, DRY, SOLID).
  • Standards and style guides: language-specific conventions like PEP 8 (Python), Airbnb JavaScript, Google Java style guide, Effective Go, and more for consistency and readability.
  • Secure SDLC: security across requirements, design, implementation, testing, deployment, and maintenance.

“From OWASP secure coding practices to SOLID and DRY, SiteShadow turns best-practice checklists into automated guardrails across your entire SDLC.”

Risk-based prioritization

SiteShadow prioritizes checks using a simple model: risk is driven by how exposed you are, what it would cost if exploited, and how likely it is to be used in the real world.

Risk = Vulnerability × Impact × Threat
and Likelihood = Vulnerability × Threat (often called “likeliness”)
so Risk = Impact × Likelihood

  • Vulnerability: how exposed you are to a weakness — the absence or strength of controls, guardrails, validation, and safe defaults.
  • Impact: the consequence if the weakness is successfully used — blast radius, data exposure, operational disruption, safety, cost, and trust.
  • Threat: how common the attack is in the wild and/or the presence of real threat actors attempting it. (The “actors exist” factor is effectively a constant 1 — what changes is prevalence and pressure.)
  • Likelihood (or “likeliness”): a convenient grouping of Vulnerability × Threat — how probable exploitation is in practice.

Risk drives priority. Higher-risk areas get deeper checks: more context, stronger validation, and tighter guardrails where the cost of being wrong is highest.