Purpose and product coverage
Security must be considered throughout development and maintenance of NexCommand software, AI workflows, integrations and supplied configurations. This policy covers code, infrastructure definitions, models, prompts, retrieval pipelines, connectors, third-party packages and release artifacts. It also applies to outsourced development and emergency fixes.
Use the NIST Secure Software Development Framework as a reference for organizing development practices. Its use does not certify a product or establish that it contains no vulnerabilities. Each project must define the practices and evidence appropriate to its technology, information and potential impact.
Planning, requirements and threat review
Assign a product owner and competent security reviewer. Record intended use, data sensitivity, trust boundaries, user roles, critical dependencies and acceptance criteria. Identify misuse cases, privilege escalation, data leakage, injection, supply-chain compromise and loss of availability relevant to the design. Review changes to those assumptions as work proceeds.
Security requirements must be testable and linked to acceptance evidence. Identify prohibited data or activities in evaluation environments. For AI systems, address untrusted retrieved content, unsafe tool use, source permissions and generated-output handling. Avoid using a prompt as the sole protection for an action that needs an enforceable authorization boundary.
Controlled implementation and dependencies
Use approved repositories, access controls, traceable changes and appropriate peer review. Protect branches, build identities and secrets. Developers must not place customer production data, credentials or controlled technical information in public issues, test fixtures or unapproved AI coding tools. Separate environments according to risk and customer duties.
Record third-party components, models, source, licenses and versions. Review maintenance status, known vulnerabilities and distribution obligations. Where an SBOM or equivalent inventory is required, maintain it for the delivered baseline. Verify supplier artifacts and restrict dependency updates through controlled review; automatic updating must not bypass required acceptance checks.
Verification and release gates
Select testing suited to the system: code review, automated analysis, dependency checks, secret detection, configuration review and targeted functional or adversarial tests. Test access denial, tenant isolation, failure handling, logging and recovery where relevant. Track findings to risk disposition and retest; a passing scanner alone does not establish secure behavior.
Critical unresolved findings require remediation, restricted use or documented release refusal. Any accepted residual risk must have a competent owner and must not violate law or contract. The release record must identify versions, changes, tests, known limitations, approvals and deployment instructions. Verify that the package contains no development secrets or unnecessary customer material.
Build integrity and deployment
Protect the build environment and credentials, limit who can create or publish releases and preserve traceability from source to artifact. Use integrity verification and signing where required by the accepted design or contract. Make rollback, configuration migration and compatibility requirements explicit. Record customer-specific deviations from the standard baseline.
Updates for disconnected systems require an approved transfer path, malware checks, recipient verification and installation evidence. Emergency fixes must still have an accountable reviewer and a record of the change, with follow-up testing proportionate to the event. Do not quietly change a model, API behavior or permission assumption that affects customer acceptance.
Vulnerability handling and support lifecycle
Maintain a route to receive vulnerability concerns, assess credibility and impact, identify affected versions and coordinate remediation. External reporters must request a secure exchange through Contact; this page grants no authorization for invasive testing. Protect reporter information and avoid exposing customer data in public advisories.
Define supported versions, dependency maintenance and end-of-support communication in the relevant agreement. Provide customers with practical mitigation and upgrade information for material issues. Coordinate disclosure with affected parties and legal obligations. Security fixes, lessons from incidents and recurring defect patterns must inform future design and testing.
Records, exceptions and review
The policy owner must maintain the records needed to demonstrate implementation: applicable requirements, named responsibilities, training, approvals, exceptions, reviews and corrective actions. Records must be access-controlled, retained under the applicable retention schedule and protected from unauthorized amendment or disposal. Legal holds and contract-specific retention requirements take precedence over routine deletion.
An exception must identify its scope, business reason, risk, compensating measures, accountable approver and expiry date. It must be approved before the affected activity proceeds and reviewed when circumstances change. No exception can authorize unlawful conduct, remove a contractual obligation or conceal a nonconformity. Unresolved issues must be escalated to executive management and the relevant professional adviser.
The policy owner reviews this policy at least annually and after a material legal, business, product or incident-driven change. Revisions require authorized approval and document control. Supporting procedures, responsibility assignments and implementation evidence are controlled records. Statements of certification or contractual compliance must identify their scope and supporting evidence.