Secure Development —
security built in,
not bolted on.

What this policy governs

This Secure Development Policy establishes the mandatory security requirements for all software development, infrastructure configuration, and deployment activity associated with the VIGIL platform operated by Anshin Risk and Resilience Consulting Private Limited (ARRC Global).

It applies to:

• All VIGIL platform code — application layer, API layer, database schema, and infrastructure configuration
• All internal tooling and scripts used in the build, test, and deployment pipeline
• All personnel involved in VIGIL development — including contractors, consultants, and any third party contributing code or configuration
• All environments — development, staging, and production

Compliance with this policy is mandatory. Any deviation requires documented approval from the founding principal before the deviation is implemented. Undocumented deviations are treated as security incidents.

The security philosophy behind every decision

• Secure by design. Security requirements are defined alongside functional requirements — not added after implementation. A feature without a security design is an incomplete design.
• Least privilege. Every component, service, user account, and API credential operates with the minimum permissions necessary for its function. Broad permissions are never granted for convenience.
• Defence in depth. No single control is relied upon to prevent a security failure. Controls are layered so that the failure of one does not expose the system.
• Fail securely. When a system component encounters an unexpected condition, it fails in a secure state — denying access, logging the event, and alerting — rather than defaulting to an open or permissive state.
• Zero trust. No component, user, or network location is implicitly trusted. All requests are authenticated and authorised, regardless of origin.
• Separation of environments. Development, staging, and production environments are strictly separated. Production data is never used in development or staging. Production credentials never appear in development environments.
• Security is everyone's responsibility. Security is not the exclusive domain of a security function. Every developer is responsible for the security of the code they write. This policy makes that responsibility explicit.

Security checkpoints across the development lifecycle

Security controls are embedded at every stage of the Software Development Lifecycle. The following gates must be passed before progression to the next stage.

• Requirements gate. Security and privacy requirements are identified and documented alongside functional requirements. Any feature handling personal data, authentication, authorisation, or external data sources requires explicit security requirements before development begins.
• Design gate. For significant new features or architectural changes, a threat model is completed before implementation. At minimum, the STRIDE framework is applied to identify spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege risks.
• Development gate. Code is written in accordance with the secure coding standards in Section 5. No code is committed without self-review against the secure coding checklist.
• Review gate. All code changes undergo peer review with explicit security assessment. Automated static analysis (SAST) scans are run before merge. Critical or high findings block merge until resolved.
• Testing gate. Security test cases covering the OWASP Top 10 are executed before any release. Automated dependency scans are run. No known critical or high vulnerabilities in production dependencies at release.
• Production gate. Release to production requires documented approval. Production deployments are logged. Rollback capability is confirmed before deployment proceeds.

Security requirements at the design stage

Threat Modelling

Threat modelling is conducted for all significant new features, architectural changes, or integrations. The output of a threat model is a documented list of identified threats, their risk rating, and the controls implemented or accepted for each. Threat models are stored in the development repository alongside the code they relate to.

Authentication Architecture

• All platform authentication uses industry-standard protocols. Session tokens use JWT with explicit expiry and rotation policies.
• Token expiry: access tokens — 15 minutes. Refresh tokens — 7 days with rotation on use.
• Multi-factor authentication (MFA) is enforced for all administrative and privileged accounts. It is available and encouraged for all platform users.
• Password requirements: minimum 12 characters, complexity enforcement, breach-password checking against known compromised credential databases at account creation and password change.
• Account lockout after 5 consecutive failed authentication attempts, with progressive delay and alert generation.

Authorisation Architecture

• Role-Based Access Control (RBAC) is applied throughout. Roles are defined by the minimum permissions required for their function — not by convenience groupings.
• Authorisation is checked server-side for every request. Client-side access controls are UI convenience only and are never the enforcement mechanism.
• Cross-client data isolation: each client organisation's data is logically isolated. No query, API call, or report can return data belonging to a different client organisation. Isolation is enforced at the data access layer, not the application layer alone.
• Privilege escalation paths are explicitly designed and restricted. No user can elevate their own permissions within the platform.

Data Minimisation

• Features collect only the data necessary for their function. Data fields are not added speculatively — each field requires a documented purpose.
• Personal data is not used in non-production environments. Where test data is required, it is synthetically generated or fully anonymised.

Mandatory practices for all code

Input Validation

• All input — from users, APIs, files, and external data sources — is validated server-side before processing. Client-side validation is supplementary only.
• Input validation uses allowlist (whitelist) logic, not denylist (blacklist). Unknown input types are rejected, not sanitised.
• File uploads are validated for type, size, and content. Uploaded files are stored outside the web root and never executed.

Output Encoding

• All output rendered in a browser is context-appropriately encoded to prevent Cross-Site Scripting (XSS). HTML encoding for HTML context; JavaScript encoding for script context; URL encoding for URL parameters.
• Content Security Policy (CSP) headers are set on all responses to restrict execution of inline scripts and unauthorised external resources.

SQL and Injection Prevention

• All database queries use parameterised queries or prepared statements. String concatenation to build SQL queries is prohibited.
• Database accounts used by the application have the minimum permissions required — read-only where read-only is sufficient. No application database account has DDL (schema modification) permissions.
• ORM-level protections are supplemented by query-level validation for complex queries.

Error Handling

• Error messages returned to users or API consumers never include stack traces, internal file paths, database schema information, or system configuration details.
• All exceptions are caught at the appropriate level, logged internally with full context, and replaced with a generic user-facing message.
• HTTP error codes are used correctly. A 404 is returned for a resource not found by the requesting user — regardless of whether the resource exists but is unauthorised (to prevent enumeration).

Cryptography

• Encryption at rest: AES-256. Encryption in transit: TLS 1.3 minimum. TLS 1.0 and 1.1 are disabled.
• Cryptographic keys are managed through a dedicated secrets management system. Keys are never hardcoded in source code or configuration files.
• Password hashing uses bcrypt or Argon2 with appropriate work factors. MD5 and SHA-1 are prohibited for password storage or any security-relevant hashing.
• Random number generation for security-sensitive purposes (tokens, session IDs, nonces) uses cryptographically secure random number generators only.

HTTP Security Headers

All platform responses include the following security headers as standard:

• Strict-Transport-Security — enforces HTTPS with a minimum max-age of 1 year, including subdomains
• Content-Security-Policy — restricts script, style, and resource sources to authorised origins
• X-Content-Type-Options: nosniff — prevents MIME-type sniffing
• X-Frame-Options: DENY — prevents clickjacking via iframe embedding
• Referrer-Policy: strict-origin-when-cross-origin — limits referrer information leakage
• Permissions-Policy — restricts access to browser APIs not required by the platform

Third-party code and supply chain security

Third-party dependencies are a primary attack surface in modern software. VIGIL's dependency management applies the following controls:

• Dependency inventory. A Software Bill of Materials (SBOM) is maintained and updated with every release, listing all direct and transitive dependencies with version numbers. The SBOM is available to enterprise clients on request.
• Automated vulnerability scanning. Dependency scanning runs automatically on every code commit and on a daily scheduled basis against the production dependency set. Findings are triaged within 24 hours of detection.
• Severity response times. Critical vulnerabilities in production dependencies: remediation or documented mitigation within 7 days. High: within 14 days. Medium: within 30 days. Low: addressed at next scheduled maintenance release.
• Approved sources only. Dependencies are sourced only from official package registries (npm, PyPI). Direct inclusion of code from unverified sources, GitHub snippets, or CDN links in production code is prohibited.
• Dependency pinning. Production dependencies are pinned to specific versions. Floating version ranges (e.g. ^ or ~ in package.json) are not used in production dependency specifications.
• Minimise surface area. Dependencies are periodically reviewed and removed if they are no longer used or if their function can be implemented with less external exposure. Unused dependencies are a security liability.
• Licence compliance. All dependencies are reviewed for licence compatibility before introduction. Dependencies with licences incompatible with commercial use are not added to the codebase.

Credentials, keys, and sensitive configuration

The exposure of credentials, API keys, cryptographic keys, or other secrets is one of the most common and consequential security failures in software development. The following controls are mandatory:

• No secrets in code. API keys, passwords, database credentials, cryptographic keys, tokens, and any other secret value are never hardcoded in source code, configuration files, comments, or documentation. This applies to all environments — including development and test.
• No secrets in version control. No secret value is committed to any version control system — including private repositories. Git history is considered permanent and insecure for secret storage.
• Secrets management system. All secrets are stored in and retrieved from a dedicated secrets management system. Access to secrets is logged, audited, and restricted to the specific services and personnel that require them.
• Environment-specific secrets. Separate secrets are maintained for development, staging, and production environments. Development secrets have no access to production systems. Production secrets are accessible only in production infrastructure.
• Secret rotation. Production secrets are rotated on a defined schedule and immediately upon any suspected or confirmed exposure. Rotation schedules are documented in the secrets management system.
• Exposure response. If a secret is confirmed or suspected to have been exposed — in code, logs, communications, or any other medium — it is treated as compromised and rotated immediately, regardless of whether exploitation has been confirmed. The exposure is logged as a security event.
• Pre-commit scanning. Automated pre-commit hooks scan for patterns matching known secret formats (API keys, tokens, connection strings) before code is committed. Commits containing detected secret patterns are blocked.

How code is validated before it ships

Peer Review Requirements

• All code changes require peer review before merge to any protected branch. No code is merged on a self-review basis.
• Reviewers explicitly assess security implications — not only functionality. The review checklist includes: input validation, output encoding, authentication and authorisation logic, error handling, dependency changes, and secrets.
• Changes to authentication, authorisation, cryptography, or data access logic require review by the most security-experienced available reviewer and are flagged for additional scrutiny.

Automated Static Analysis (SAST)

• Static Application Security Testing runs automatically on all pull requests and commit pipelines. Results are reviewed before merge approval.
• Critical and high findings block merge. Medium findings are reviewed and either resolved or documented with an accepted-risk justification before merge. Low findings are tracked and addressed in maintenance releases.

Security Testing

• Security test cases covering the OWASP Top 10 are maintained and executed as part of the test suite for each release. New features include security test cases as part of their acceptance criteria.
• API endpoints are tested for authentication bypass, authorisation bypass (IDOR), rate limiting, and input validation before release.
• Regression tests are written for every confirmed vulnerability that is remediated — to prevent reintroduction in future releases.

Dynamic Analysis & VAPT

• Dynamic Application Security Testing (DAST) is run against the staging environment before major releases.
• Independent VAPT is conducted at least annually by a CERT-In empanelled security firm, covering the full platform including all new modules added in the preceding year. See the Responsible Disclosure Policy for how external researchers can contribute to security testing.

Security controls at the point of release

• Environment separation. Development, staging, and production are separate environments with separate credentials, separate access controls, and no shared secrets. Developers do not have direct write access to production systems.
• Release approval. Every production release requires documented approval. The release record includes: the changes included, the security review outcome, the SAST scan result, and the approver's identity.
• Deployment pipeline integrity. The CI/CD pipeline is treated as a security-critical system. Pipeline configuration is version-controlled, access to modify pipeline configuration is restricted, and pipeline execution logs are retained for audit purposes.
• Immutable deployments. Production deployments use immutable artefacts built from verified source at a specific commit reference. Post-deployment modification of running code is prohibited — changes require a new deployment through the pipeline.
• Rollback capability. The ability to roll back to the previous production release is confirmed before every deployment. Rollback procedures are documented and tested.
• Post-deployment verification. After every production deployment, automated smoke tests and security header checks confirm that the deployment is functioning correctly and that security configurations have been applied as expected.
• Change freeze windows. Production deployments are not made during critical client assessment periods or scheduled maintenance windows communicated to clients, except for emergency security patches.

From discovery to resolution

• Discovery sources. Vulnerabilities are identified through: automated dependency scanning, SAST findings, DAST results, annual VAPT, responsible disclosure reports from external researchers, and internal security reviews.
• Triage. Every identified vulnerability is triaged within 24 hours of discovery. Triage assigns a severity rating (using CVSS where applicable), an owner, and a target remediation date.
• Severity-based response times:
  • Critical — immediate response; remediation or documented mitigation within 7 days; emergency deployment if required
  • High — remediation within 14 days; interim mitigation implemented within 48 hours if full remediation requires longer
  • Medium — remediation within 30 days; addressed in next planned release
  • Low — remediation within 60 days; addressed in scheduled maintenance release
  • Informational — logged and reviewed at next scheduled security review
• Regression prevention. Remediated vulnerabilities are covered by regression tests before the fix is deployed. No vulnerability is closed as resolved without a passing regression test.
• Client notification. For confirmed vulnerabilities that affect client data or platform availability, clients are notified in accordance with the Incident Response Plan and applicable DPA terms.
• Vulnerability register. A vulnerability register is maintained recording all identified vulnerabilities, their status, severity, owner, target date, and resolution. The register is reviewed at each security review cycle.

How VIGIL addresses the OWASP Top 10

VIGIL's development practices are explicitly aligned to the OWASP Top 10 (2021). The following documents the control applied to each risk category.

Accountability across the development function

• Founding Principal. Policy owner. Approves deviations. Reviews policy annually. Final accountability for security posture.
• All developers. Mandatory compliance with secure coding standards, secrets management rules, and peer review requirements. Responsible for completing security review checklist on all pull requests. Required to complete security awareness training annually and when significant new threats emerge.
• Code reviewers. Responsible for explicit security assessment during peer review — not functional review only. Must block merges with unresolved critical or high security findings.
• Release approver. Responsible for confirming all security gates are satisfied before approving a production deployment. Release approval is a security responsibility, not only a functional one.

Policy maintenance and document access

This policy is reviewed annually and updated whenever a material change in platform architecture, development practices, or applicable standards requires it. Changes to the OWASP Top 10 or ASVS that affect VIGIL's controls trigger an immediate policy review.

Enterprise clients and procurement teams requiring the full Secure Development Policy document — including implementation procedures, ASVS mapping, and code review checklists — may request it below.