Skip to main content

Secure Development

To establish a baseline of minimum-security requirements and best practices required for all software development activities to minimize vulnerabilities, reduce risks, and ensure confidentiality, integrity, and availability (CIA) of systems and data throughout the Software Development Life Cycle (SDLC). These minimum requirements are aligned with industry standards and frameworks such as NIST, OWASP, and ISO/IEC 27034.

This guideline applies to:

  • All internally and externally developed or maintained software.
  • All personnel involved in software development, testing, deployment, maintenance, or support.
  • All environments (Development, Testing, Staging, UAT, and Production).

Access Control Management​

An Access Control policy and procedure shall be defined, documented, approved, and reviewed at least annually to govern and enforce user access to systems and data.

  • Least Privilege and Need-to-Know principles shall be strictly enforced for all users, systems, and applications.
  • All user accounts must be provisioned through a formal request and approval process, documented and authorized by appropriate personnel.
  • Role-Based Access Control (RBAC) shall be enforced across development and operational environments to ensure consistent and secure access assignment.
  • Shared accounts are strictly prohibited. All accounts must be uniquely identifiable and traceable to an individual.
  • Multi-Factor Authentication (MFA) shall be implemented for all administrative, remote access, cloud-based services, and access to sensitive data or systems.
  • Privileged access shall be implemented:
    • Minimally assigned and limited to operational necessity;
    • Documented in an access inventory;
    • Solution (session record, vaulting…) shall be considered to implement;
    • Privileged access activities shall be subject to session monitoring and reviewed through centralized logging platforms;
    • Reviewed at least quarterly to validate continued need and appropriateness.
  • Access shall be revoked immediately upon user termination, transfer, or change in job responsibilities to minimize unauthorized access risks.
  • Account activity logging must be enabled per the Logging and Monitoring Standard and integrated with centralized monitoring mechanisms where applicable.
  • A User Access Rights Matrix shall be developed, maintained, and reviewed semi-annually, or upon changes to roles, responsibilities, or organizational structure.
  • Quarterly access reviews must be performed by designated owners to verify appropriateness of access rights. Additional reviews shall occur during:
    • User onboarding and offboarding;
    • Departmental restructures or changes in business functions;
    • Review logs shall be retained for a minimum period of one (1) year for audit and compliance purposes.
  • Third-party access must be governed by formal agreements and treated equivalently to internal access.

Password Management​

Password management policy and procedure shall be established to enforce strong password control for user's access to systems or applications.

  • Passwords must:
    • Be at least 12 characters in length.
    • Contain uppercase, lowercase, numbers, and special characters.
    • Support passphrases where systems allow.
    • Avoid reuse of the last 5 passwords.
    • Enforce account lockout mechanism after 5 failed login attempts.
  • Inactivity timeout (session timeout) shall be configured with a maximum of 15 minutes of inactivity.
  • Passwords must not be hardcoded or stored in plaintext.
  • Secrets management tools (e.g., HashiCorp Vault, CyberArk) shall be considered to securely store credentials and secrets.

Change Management​

Change management policy and procedure shall establish to ensure that changes to production systems are evaluated, authorized, executed, documented, and reviewed.

  • Classify changes into categories: Standard, Normal, or Emergency, with appropriate workflows and approvals for each type.
  • All changes must follow a formal change request process, including: request description, justification, impact/risk analysis, review and approvals, and documented rollback/recovery plan.
  • Changes must be scheduled during defined maintenance windows, unless pre-approved under emergency procedures.
  • All changes must be peer-reviewed, documented, and signed off prior to deployment.
  • Subject to functional and regression testing to ensure application stability.
  • Security scanning tools (SAST, DAST) shall be considered to implement in the CI/CD pipeline.
  • All code and configurations must be maintained under version control (e.g., Git), ensuring clear audit trails and rollback capability.
  • CI/CD pipeline tools (e.g., GitLab CI, Jenkins, Azure DevOps) shall be considered to implement with proper SoD, artifact signing, and integrity checks.
  • Validation testing must confirm that the change achieved its intended purpose without introducing new issues.
  • Enable monitoring and logging post-deployment to detect anomalies or failures.
  • Conduct a post-implementation review for all emergency changes and any change that results in service degradation or failure.
  • Emergency changes must be fully documented and reviewed retrospectively.

Vulnerability Management & Penetration Testing​

A Vulnerability Management and Penetration Testing policy and procedure shall be established to assess the IT environment continuously.

  • Conduct regular vulnerability scans, code assessments, and security testing.
  • Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) tools shall be considered to implement and integrated into CI/CD pipelines to ensure continuous vulnerability assessment of source code, running applications, and third-party components before deployment.
  • Scan all third-party libraries, open-source dependencies, and container images.
  • Conduct Penetration Testing annually or upon major changes or new releases.
  • Remediate vulnerabilities based on CVSS v3.1 severity:
    • Critical: within 7 days;
    • High: within 14 days;
    • Medium: within 30 days;
    • Low: within 90 days;
  • Maintain records and document exceptions for SLA violations.

Secure Coding Practices​

A Secure Coding policy and procedure shall be adopted and aligned development frameworks (e.g., NIST SSDF, OWASP Top 10, CWE/SANS Top 25):

  • All user inputs must be validated for type, length, format, and range on both client and server side.
  • All user inputs must be properly encoded before use in HTML, JavaScript, SQL, or other outputs.
  • Session IDs must be regenerated upon login, use 128-bit+ entropy tokens, and timeout after 15 minutes of inactivity.
  • Encrypt all stored sensitive data and sent over the internet by using strong encryption method AES-256 (symmetric), RSA-2048 / ECC P-256+ (asymmetric), SHA-256+ (hashing), and TLS 1.2+ for communications.
  • Certificate pinning shall be considered for high-risk applications.
  • Cryptographic algorithms and configurations shall be reviewed periodically.
  • Passwords must be stored securely using salted hashing (bcrypt, PBKDF2) and never in plaintext or reversible formats.
  • Use parameterized queries or prepared statements to prevent SQL injection.
  • Limit database privileges to the minimum needed; regularly audit permissions and monitor for anomalous access.
  • Do not expose internal error messages to end users.
  • Automated security testing (SAST, DAST, SCA) must be integrated into CI/CD pipelines.
    • SAST (Static Application Security Testing) – to check code before it runs.
    • DAST (Dynamic Application Security Testing) – to test running apps for vulnerabilities.
    • SCA (Software Composition Analysis) – to check libraries and dependencies for known vulnerabilities.
  • Only trusted and up-to-date third-party libraries shall use; SBOM (Software Bill of Materials) generation and management tools should be considered.
  • Integrity of third-party components must be validated using checksums, hashes, or artifact signing.
  • Continuously monitor components for known vulnerabilities and promptly remediate or replace affected components.
  • Secrets (API keys, tokens) must not be hardcoded; secure storage in HSMs or key vaults (e.g., AWS KMS, Azure Key Vault) shall be considered.
  • Secure coding checklists must be integrated into code review and release processes.
  • Enforce use of OWASP ASVS levels (e.g., Level 2 for internal business-critical application, Level 3 for public-facing, sensitive data or high-value systems).
  • All code changes must be peer reviewed for compliance before deployment.
  • All developers must complete secure coding training annually.

Secure Software Development Life Cycle (SDLC)​

A Secure SDLC policy and procedure shall be established to integrates security practices throughout the development lifecycle.

  • Document both High-Level Design (HLD) and Low-Level Design (LLD), including security architecture.
  • Segregation of Duties (SoD) must be implemented:
    • Developers, team leads, and managers should have clearly defined roles.
    • Separate development, testing, and deployment responsibilities.
    • Developers must not access production systems or databases without time-bound, documented exception approvals.
    • Production deployments are restricted to authorized personnel.
  • All source code must be version-controlled and stored securely.
  • Code reviews must be performed before release to ensure security and quality.
  • Security tools such as SAST (Static Application Security Testing) and SCA (Software Composition Analysis) must be part of the process.
  • The source code must be protected from unauthorized access.
  • Integrate Software Supply Chain Security into SDLC:
    • Create a Software Bill of Materials (SBOM) before releasing any software build.
    • Use only trusted, verified third-party libraries and components.
    • Validate integrity of components using checksums, hashes, or artifact signing during build and deployment.
    • Regularly review and reassess third-party and open-source components for security risks and maintenance status.
  • Maintain environmental separation:
    • Development: Only accessible to developers.
    • UAT: must not have internet access by default; enable only through documented approval
    • Production: Live data only; no direct developer access.
  • Testing and Validation:
    • Conduct functional, performance, and security testing (including penetration testing, DAST, where applicable).
    • All vulnerabilities must be remediated or formally risk-accepted before release.
    • Obtain formal sign-off on all test results prior to production deployment.
  • Enforce change control procedures, including formal approvals, rollback plan and deployment logs.
  • No production deployment without completion of required approvals and validations.
  • Conduct post-release reviews and update SDLC practices accordingly.
  • All developers must complete annual secure SDLC training.

Incident Response Management​

Incident management policy and procedure shall be established to detect, respond to, and mitigate IT incident, including cyber security incidents.

  • Report all incidents involving development or code repositories immediately.
  • Centralized logging and monitoring platforms, including immutable logging tool (e.g., Splunk…), shall be considered to implement to provide secure, tamper-evident audit trails for all CI/CD and source code management activities.
  • Log retention: Minimum 1 year.
  • Include incident simulation exercises for secure development scenarios.
  • Integration of secure coding lessons learned into SDLC updates after incident closure.
  • Conduct root cause analysis and improve controls post-incident.

Backup and Recovery​

Backup and recovery policy and procedure shall be established to cover the life cycle of backup and recovery process.

  • All backups shall be encrypted to protect sensitive information in transit and at rest, using industry-standard encryption algorithms (e.g., AES-256).
  • Backup schedule:
    • Daily backups for code repositories.
    • Weekly backups for full system configurations.
  • Testing: Restore backups at least once every quarter to confirm they work.
  • Retention: Keep backups for at least 90 days, with an additional secure copy stored offsite or in an air-gapped environment for production systems.
  • Backup tools: Consider using solutions like Veeam or similar that support:
    • AES-256 encryption support
    • Role-Based Access Control (RBAC).
    • Multi-Factor Authentication (MFA).
    • Integrity checks to verify backup data has not been altered.
  • Encryption keys used for backups must be securely stored, recoverable, and tested periodically.
  • Documented DR procedures shall exist and be tested regularly to ensure quick recovery in case of emergencies.