Secure Coding Standard
Purpose
Section titled “Purpose”Security controls begin in design and implementation rather than at the scanner.
Nexa context
Section titled “Nexa context”Nexa services handle authentication, model interactions, platform credentials, job orchestration, speech input, and multi-cloud APIs. Business-logic abuse and authorization mistakes may not be detected by generic scanners.
Standard
Section titled “Standard”-
MUST: Validate and constrain external input at trust boundaries.
-
MUST: Perform authorization checks server-side for every protected operation.
-
MUST: Do not log secrets, access tokens, sensitive prompts, customer payloads, or raw credentials.
-
MUST: Use parameterized APIs and safe SDK methods rather than command or query string concatenation.
-
MUST: Define timeouts, retries, and bounded resource consumption for remote calls.
-
MUST: Return safe errors externally while preserving actionable internal diagnostics.
-
SHOULD: Threat-model new externally reachable capabilities and privileged automation.
-
SHOULD: Use allow-lists for supported model providers, commands, file types, and destinations where practical.
-
SHOULD: Review dependency and SDK defaults rather than assuming they are secure.
Working model
Section titled “Working model”Design review identifies assets, actors, trust boundaries, abuse cases, and failure behavior. Implementation adds validation, authorization, safe error handling, and tests for denied paths. CI scanners provide a second line of defence.
Evidence of compliance
Section titled “Evidence of compliance”Compliance is demonstrated through repository configuration, protected-branch settings, CI results, and review records. Teams should be able to show the evidence without reconstructing it manually.
Common failure modes
Section titled “Common failure modes”Scanner-clean code can still expose insecure direct object references, excessive privileges, prompt injection pathways, unsafe agent tools, or destructive automation without confirmation.
Maturity path
Section titled “Maturity path”The initial standard favors consistency and auditable automation. Exceptions and advanced controls are introduced only after the baseline is adopted across repositories.