Secure Software Development Lifecycle Policy - NEO - Global Employment Marketplace Platform

1.0 OVERVIEW

This Secure Software Development Lifecycle (SSDLC) policy establishes comprehensive security requirements for all phases of software development in accordance with ISO 27001:2022, specifically addressing Annex A.8.25 (Secure development lifecycle) and A.8.28 (Secure coding). The policy ensures that security is integrated throughout the development process to protect against cyber threats and maintain the confidentiality, integrity, and availability of NEO’s applications and data.

2.0 PURPOSE & BACKGROUND

The purpose of this policy is to establish mandatory security requirements for the entire software development lifecycle at NEO, ensuring that:

Security by Design: Security considerations are integrated from the earliest phases of development
ISO 27001:2022 Compliance: All development activities align with ISO 27001:2022 requirements
Risk Management: Development practices effectively identify, assess, and mitigate security risks
Supply Chain Security: Third-party components and dependencies are securely managed
Configuration Management: Secure configuration practices are maintained throughout development

This policy applies to all software development activities including web applications, mobile applications, APIs, microservices, and supporting infrastructure code. It must be used in conjunction with NEO’s Information Security Policy and encompasses both internally developed software and third-party integrations.

3.0 SCOPE AND APPLICABILITY

This policy applies to all personnel involved in software development activities at NEO, including:

Personnel:

Software developers and engineers
DevOps and infrastructure engineers
Quality assurance and testing teams
Product managers and architects
Security engineers and reviewers
Third-party developers and contractors
Vendor development teams working on NEO projects

Development Lifecycle Phases:

Requirements Analysis: Security requirements definition and threat modeling
Design: Secure architecture design and security controls specification
Development: Secure coding practices and code security reviews
Testing: Security testing, vulnerability assessment, and penetration testing
Deployment: Secure deployment practices and configuration management
Maintenance: Ongoing security monitoring, patching, and updates
Decommissioning: Secure disposal of applications and data

Application Types:

Customer-facing web applications
Internal business applications
Mobile applications (iOS/Android)
API services and microservices
Infrastructure as Code (IaC)
Third-party integrations and plugins

4.0 SECURE DEVELOPMENT LIFECYCLE REQUIREMENTS (ISO 27001:2022)

4.1 Secure Development Environment

Environment Segregation and Security:

Local Development: Individual developer environments with secure configuration baselines
Development: Integration environment for preliminary testing and code merging
Testing: Automated and manual testing environment with production-like data protection
QA Environment: Customer acceptance testing with data anonymization/pseudonymization
Demo Environment: Customer demonstration environment with synthetic data only
Production: Live environment with full security controls and monitoring

Environment Security Controls:

Network segmentation between environments
Access controls based on principle of least privilege
Environment-specific encryption keys and certificates
Secure configuration management for all environments
Regular security assessments and vulnerability scanning
Data masking/anonymization for non-production environments

Production Environment Access:

Limited to authorized personnel for critical incident response
All production access logged and monitored in real-time
Break-glass procedures documented and tested
Mandatory multi-factor authentication (MFA) for production access
Time-limited access tokens with automatic expiration
Comprehensive audit trail of all production activities

4.2 Security Requirements Integration

Requirements Phase Security:

Security requirements must be defined for all applications
Threat modeling conducted during requirements analysis
Privacy impact assessments for applications processing personal data
Compliance requirements mapping (GDPR, industry standards)
Security acceptance criteria defined for user stories

Design Phase Security:

Security architecture reviews for all major applications
Secure design patterns and frameworks mandated
Data flow diagrams including security controls
Cryptographic requirements specification
Authentication and authorization architecture design

4.3 System Functionality and Security Testing

Mandatory Security Testing:

Static Application Security Testing (SAST) integrated into CI/CD pipeline
Dynamic Application Security Testing (DAST) for all web applications
Interactive Application Security Testing (IAST) for runtime vulnerability detection
Container image vulnerability scanning before deployment
Infrastructure as Code (IaC) security scanning
Dependency vulnerability scanning for all third-party components

Testing Requirements:

Automated security tests run on every code commit
Manual penetration testing conducted annually by external providers
Security regression testing for all major changes
Performance testing under security stress scenarios
API security testing including authentication and authorization
Mobile application security testing (if applicable)

Audit and Monitoring Preparation:

Security logging requirements defined before system deployment
Audit trail specifications documented and implemented
Monitoring and alerting configurations established
Incident response procedures integrated with security monitoring
Compliance reporting capabilities built into applications

End-of-Life and Dependency Management:

Automated scanning for vulnerable and outdated dependencies
Regular updates of libraries and frameworks to latest secure versions
End-of-life component replacement planning and implementation
Security patch management integrated with change control processes
Vendor security advisory monitoring and response procedures

5.0 SECURE CODING PRACTICES (ISO 27001:2022 A.8.28)

5.1 Code Review and Development Workflow

Mandatory Code Review Process:

Draft Stage: Early feedback and security consideration review
Security Review: Dedicated security-focused review for critical components
Peer Review: Technical and security review by qualified team members
Approval: Final approval with security sign-off before merge
No Direct Commits: All production code must go through review process

Security-Focused Code Review Checklist:

Input validation and output encoding implementation
Authentication and authorization mechanisms
Cryptographic implementation verification
Error handling and information disclosure prevention
SQL injection and other injection attack prevention
Cross-site scripting (XSS) prevention measures
Cross-site request forgery (CSRF) protection
Secure session management implementation
Logging and monitoring integration

5.2 Secure Coding Standards

OWASP Guidelines Compliance:

OWASP Top 10 vulnerabilities prevention mandatory
OWASP Secure Coding Practices implementation
OWASP Application Security Verification Standard (ASVS) alignment
Regular updates based on latest OWASP guidance

Language-Specific Security Requirements:

Use of secure coding frameworks and libraries
Avoiding deprecated or insecure functions
Memory management best practices (where applicable)
Secure configuration of development frameworks
Regular security linting and static analysis

Data Protection in Code:

Encryption of sensitive data at rest and in transit
Secure handling of personal and confidential information
Proper data sanitization and validation
Secure disposal of temporary data and objects
Privacy by design implementation

5.3 Configuration Management and Version Control

Secure Configuration Management:

All configuration managed through version control
Environment-specific configuration separation
Secure secrets management (no hardcoded credentials)
Configuration drift detection and remediation
Infrastructure as Code (IaC) security scanning

Version Control Security:

Branch protection rules enforced
Signed commits required for critical repositories
Access controls based on least privilege principle
Audit logging of all repository activities
Regular access reviews and cleanup

Data Migration Security:

Security review mandatory for all migration scripts
Data validation and integrity verification
Rollback procedures tested and documented
Migration testing in isolated environments
Comprehensive logging of migration activities

Input Validation (Where Applicable):

Conduct all data validation on a trusted system (e.g., The server)
Identify all data sources and classify them into trusted and untrusted. Validate all data from untrusted sources (e.g., Databases, file streams, etc.)
There should be a centralized input validation routine for the application
Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect)

Output Encoding (Where Applicable):

Conduct all encoding on a trusted system (e.g., The server)
Utilize a standard, tested routine for each type of outbound encoding
Sanitize all output of un-trusted data to operating system commands

Authentication and Password Management:

Require authentication for all pages and resources, except those specifically intended to be public
All authentication controls must be enforced on a trusted system (e.g., The server)
Establish and utilize standard, tested, authentication services whenever possible
Segregate authentication logic from the resource being requested and use redirection to and from the centralized authentication control

Session Management:

Use the server or framework’s session management controls. The application should only recognize these session identifiers as valid
Session management controls should use well-vetted algorithms that ensure sufficiently random session identifiers
Set the domain and path for cookies containing authenticated session identifiers to an appropriately restricted value for the site
Logout functionality should fully terminate the associated session or connection

Access Control:

Use only trusted system objects, e.g. server side session objects, for making access authorization decisions
Use a single site-wide component to check access authorization. This includes libraries that call external authorization services
Deny all access if the application cannot access its security configuration information
Implement Role-Based Access Control (RBAC) to restrict access to sensitive data and functionality based on user roles

Cryptographic Practices:

All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system (e.g., The server)
Protect master secrets from unauthorized access
Establish and utilize a policy and process for how cryptographic keys will be managed

Error Handling and Logging:

Do not disclose sensitive information in error responses, including system details, session identifiers or account information
Use error handlers that do not display debugging or stack trace information
Implement generic error messages and use custom error pages
The application should handle application errors and not rely on the server configuration
Ensure logs contain important log event data

Data Protection:

Implement least privilege, restrict users to only the functionality, data and system information that is required to perform their tasks
Protect all cached or temporary copies of sensitive data stored on the server from unauthorized access and purge those temporary working files a soon as they are no longer required.
Encrypt highly sensitive stored information, like authentication verification data, even on the server side. Always use well-vetted algorithms, see “Cryptographic Practices” for additional guidance
Protect server-side source-code from being downloaded by a user

Communication Security:

Implement encryption for the transmission of all sensitive information. This should include TLS for protecting the connection and may be supplemented by discrete encryption of sensitive files or non- HTTP based connections
Specify character encoding for all connections
The use of unsecured/unencrypted file transport protocols/services: Communication protocols between our services are highly secure. We are using the latest version of Transport Layer Security on every exposed endpoint and continuously improving our security standards.

Refer to the OWASP quick reference guide checklist for more secure coding/development practices.

#	Guideline
1	Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.
2	There should be documented standards/procedures for administering the application and updated periodically.
3	Potential security weaknesses / breaches should be identified. There should be measures to reduce the risk of theft, fraud, error and unauthorized changes to information through measures like supervision of activities and segregation of duties.
4	Applications must not allow unauthorized entries to be updated in the database. Similarly, applications must not allow any modifications to be made after an entry is authorized. Any subsequent changes must be made only by reversing the original authorized entry and passing a fresh entry.
5	Robust input validation controls, processing and output controls needs to be built in to the application. Validations should be included on all critical pages so that attacks are minimized and no manipulation can be allowed to change data at source.
6	Critical Applications to provide for, logging unsuccessful logon attempts, access to sensitive options in the application, e.g., master record changes, granting of access rights, use of system utilities, changes in system configuration, etc.
7	The information security related requirements are included in the requirements for the development of the new information systems or enhancements in the existing information systems.
8	Besides business functionalities, security requirements relating to system access control, authentication, transaction authorization, data integrity, system activity logging, audit trail, security event tracking and exception handling are required to be clearly specified at the initial stages of system development/acquisition.
9	Any changes to an application system/data need to be justified by genuine business need and approvals supported by documentation and subjected to a robust change management process.

5.0 ROLES & RESPONSIBILITIES

Applicable to all system administrators, coders, and developers; no exceptions.

6.0 COMPLIANCE

NEO reserves the right to audit networks, systems, and applications on a periodic basis to ensure compliance with this policy.