1. Distinct methods and accountable ownership
Static Application Security Testing (SAST) analyzes application source code for security weaknesses. Dynamic Application Security Testing (DAST) evaluates a running application through its exposed interfaces. Each report must identify its actual method; a build, linter, type checker, or unit test must not be relabeled as SAST or DAST.
The engineering owner assigns a test operator and a security reviewer, maintains the application inventory, and records the scope and any unsupported languages or unreachable features. Software-composition analysis and secret scanning are complementary controls with separately identified results.
2. SAST coverage and required cadence
- Establish a baseline for in-scope repositories. Require SAST for security-sensitive changes and before production releases affecting application code; review the complete in-scope codebase at least quarterly.
- Use language-appropriate security rules covering applicable injection, unsafe data handling, authentication and authorization flaws, cryptographic misuse, and sensitive-data exposure. Record the tool and version, rule set, commit, scanned paths, and exclusions.
- Review findings for exploitability and false positives. Retain the original output and each disposition rather than silently suppressing findings. A missing scan or coverage gap must be recorded and must not be described as a clean result.
3. DAST authorization, coverage, and required cadence
- Establish an authorized baseline and require DAST at least quarterly and before releases with material changes to authentication, permissions, APIs, or data flows. Test a representative isolated environment; production testing requires separate written authorization.
- Define the permitted hosts, paths, test accounts, testing window, rate limits, stop conditions, and data-cleanup procedure. Use synthetic data where possible. Do not scan third-party services, customer systems, or provider endpoints without their authorization.
- Cover unauthenticated and authenticated flows, role and Team boundaries, APIs, OAuth callbacks and state handling, session protections, CSRF, XSS, injection, security headers, and error leakage as applicable.
- Record the deployed application version, environment, scanner and version, configuration, crawl/authentication coverage, test dates, and exclusions. Manually validate business-logic and isolation cases that automated crawling cannot cover.
4. Triage, remediation, and release gates
- Assign every validated finding a severity, affected component, accountable owner, remediation priority, and review date. Consider exploitability, exposure, and data impact alongside any CVSS score.
- Known exploitable critical findings block release and require immediate containment review. High findings require remediation or documented compensating controls, security approval, and a time-limited exception before release.
- Retest the affected path after a fix and preserve evidence of the result. Track unresolved findings and expired exceptions explicitly; do not infer closure from a successful build or an unrelated test.
5. Required evidence
Each assessment record must contain its owner and reviewer, authorization, dates, exact target version, method and configuration, coverage and exclusions, findings, triage decisions, remediation changes, and retest outcome. Protect the reports and retain them for at least 12 months under the security overview's evidence requirements.
A summary may state only the methods and targets actually tested. An assessment of the public website does not establish that Portal, Gateway, or connector services were scanned. Record an unavailable or failed test as such rather than reporting a pass.
Questions and evidence requests
Contact [email protected] for security policy questions, evidence requests, or corrections to this disclosure. Do not include passwords, access tokens, or sensitive customer data in an initial message.
Related documents: security overview, Privacy Policy, and Terms of Service.