Elevate requirements to organizational/architectural policy
- Security: no IAM in service repos, no custom auth, no direct external calls - Architecture: no cross-cloud SDKs, no cross-service DB access, no hardcoded tenant/env config - DevOps: Foxtrot-compatible Helm (no custom ingress), no infra provisioning in service repos, no pinned infra versions - Cost: resource tagging, no unbounded allocation, no per-tenant infra - Updated checker and demo to match - These are NOT static code analysis — they catch organizational policy violations that SonarQube/Checkstyle miss
This commit is contained in:
@@ -1,54 +1,28 @@
|
||||
# Security Requirements
|
||||
|
||||
Phase: implementation
|
||||
Enforcement: informational (graduating to blocking Q3 2026)
|
||||
Enforcement: informational
|
||||
|
||||
## SEC-001: Input Validation
|
||||
## SEC-001: No IAM Resources in Service Repos
|
||||
|
||||
All external input (API request bodies, query parameters, headers, file uploads) MUST be validated through a schema validator before processing.
|
||||
Service repositories MUST NOT contain IAM policies, roles, or identity resources. IAM is centrally managed by the security team through the infrastructure repo.
|
||||
|
||||
**Rule:** No raw request body access in business logic. All endpoints must define and validate against a schema (JSON Schema, protobuf, or framework-equivalent).
|
||||
**Rule:** No Terraform/CloudFormation IAM resource definitions (`aws_iam_role`, `aws_iam_policy`, `google_project_iam_member`, etc.) in service-level repositories. If your service needs a new permission, request it through the IAM change process.
|
||||
|
||||
**Test:** Grep for direct `request.body` / `req.body` / `getParameter()` usage outside of controller/validation layer.
|
||||
**Test:** Scan IaC files for IAM resource type declarations.
|
||||
|
||||
```
|
||||
# Bad
|
||||
String name = request.getParameter("name");
|
||||
db.query("SELECT * FROM users WHERE name = '" + name + "'");
|
||||
## SEC-002: No Embedded Credentials or Auth Bypass
|
||||
|
||||
# Good
|
||||
ValidatedInput input = validator.validate(request, CreateUserSchema.class);
|
||||
userService.create(input);
|
||||
```
|
||||
Services MUST NOT implement their own authentication mechanisms. All auth flows go through the centralized auth service.
|
||||
|
||||
## SEC-002: No Raw SQL
|
||||
**Rule:** No custom JWT validation, no local user tables, no auth middleware that bypasses the platform auth layer. Services consume auth tokens validated by the platform.
|
||||
|
||||
All database queries MUST use parameterized queries or an ORM. No string concatenation in SQL statements.
|
||||
**Test:** Scan for JWT libraries imported outside the auth module, custom `login`/`authenticate` endpoints, local user/password tables in migrations.
|
||||
|
||||
**Rule:** Zero tolerance for SQL string concatenation with user-controlled values.
|
||||
## SEC-003: No Direct External Network Calls Without Proxy
|
||||
|
||||
**Test:** Regex scan for SQL keywords adjacent to string concatenation operators (`+`, `concat`, `format`, `f"`, template literals).
|
||||
Services MUST NOT make direct outbound HTTP calls to external (non-Reltio) endpoints. All external traffic routes through the API gateway/proxy layer.
|
||||
|
||||
## SEC-003: Authentication Annotations
|
||||
**Rule:** Outbound calls to third-party APIs must go through the approved proxy/gateway. No hardcoded external URLs in service code.
|
||||
|
||||
All new REST endpoints MUST have an explicit auth annotation. No endpoint may be implicitly public.
|
||||
|
||||
**Rule:** Every `@RequestMapping`, `@GetMapping`, `@PostMapping` (or equivalent) must be accompanied by `@ReltioSecured` or `@PublicEndpoint`. Missing annotation = violation.
|
||||
|
||||
**Test:** AST/regex check that every endpoint method has an auth annotation.
|
||||
|
||||
## SEC-004: Secrets in Code
|
||||
|
||||
No hardcoded secrets, tokens, passwords, or API keys in source code.
|
||||
|
||||
**Rule:** All secrets must come from environment variables, vault, or config service. String literals matching secret patterns are violations.
|
||||
|
||||
**Test:** Regex scan for patterns: API keys, JWT tokens, passwords in string literals, base64-encoded credentials.
|
||||
|
||||
## SEC-005: Dependency Vulnerability
|
||||
|
||||
No new dependencies with known critical/high CVEs.
|
||||
|
||||
**Rule:** Any new dependency added to `pom.xml`, `package.json`, `go.mod`, or equivalent must pass a vulnerability scan.
|
||||
|
||||
**Test:** Run `npm audit` / `mvn dependency-check:check` / `govulncheck` on changed dependency files.
|
||||
**Test:** Scan for HTTP client instantiation with non-internal hostnames.
|
||||
|
||||
Reference in New Issue
Block a user