Secure Coding Policy #

TLDR: Think about security from the start. Know OWASP Top Ten and apply it to your code.

Rationale: Commitment to secure code aligns with our philosophy of continuous improvement and our goal to stay ahead of emerging threats

At Stacc, we recognize the critical importance of delivering code that adheres to rigorous security standards. Our commitment to security aligns with our philosophy of continuous improvement and our goal to stay ahead of emerging threats. The following policy outlines our approach to integrating security throughout the Software Development Lifecycle (SDLC) to protect our applications, data, and reputation.

Security integration in the Software Development Lifecycle (SDLC) #

Security is a fundamental aspect of Stacc’s SDLC and is embedded at every stage. The reasons for this are clear:

• Trust: Secure applications build and maintain user trust, which enhances user loyalty and strengthens our brand reputation.
• Compliance: Meeting regulatory requirements for data protection is mandatory to avoid fines, maintain our reputation, and retain customer confidence.
• Financial Protection: Preventing security breaches helps mitigate financial losses, reduces incident response costs, and minimizes potential damage to our brand.
• Integrity: Ensuring the integrity of our applications and the data they process is critical to safeguarding against unauthorized access and manipulation.

Risks of neglecting secure coding practices #

Failure to adhere to secure coding practices exposes Stacc to several significant risks:

• Data breaches: Unsecured applications risk exposing sensitive information, leading to legal liabilities and financial penalties.
• Reputation damage: A security incident can irreparably damage the reputation we have built over the years.
• Increased operational costs: Addressing security flaws retroactively is significantly more costly than investing in preventative measures during development.
• Business disruption: Security breaches can disrupt operations, causing financial losses and degrading the quality of service provided to our users.

Key security principles #

OWASP Top Ten Principles #

OWASP.org

1. Broken Access Control (OWASP A01:2021) #

Access control failures occur when users can access resources or perform actions that they are not authorized to.

• Examples:

  • Users modifying URLs to access unauthorized data (e.g., changing /account/1234 to /account/5678 to access another user’s account).
  • Missing or ineffective access control checks on sensitive operations such as administrative functions, file uploads, or access to API endpoints.
  • Lack of proper access control implementation in applications, allowing privilege escalation, where regular users perform administrative actions.

• Implementation Tips:

  • Enforce least privilege by ensuring that each user has only the minimum permissions necessary for their role.
  • Use server-side controls and never rely on client-side checks (like JavaScript) to enforce access controls.
  • Implement consistent role-based access control (RBAC) or attribute-based access control (ABAC) models across all application layers.

2. Cryptographic Failures (OWASP A02:2021) #

Cryptographic failures occur when sensitive data is not properly protected, either in storage or during transmission.

• Examples:

  • Storing passwords in plain text or using weak hashing algorithms like MD5 or SHA-1.
  • Failure to encrypt sensitive data such as personally identifiable information (PII), financial data, or health records.
  • Using outdated or insecure cryptographic protocols (e.g., SSL 2.0/3.0 or TLS 1.0) for data transmission.

• Implementation Tips:

  • Use strong, up-to-date encryption standards, such as AES-256 for data at rest and TLS 1.2+ for data in transit.
  • Utilize modern, well-maintained libraries and frameworks for cryptographic functions rather than implementing custom encryption algorithms.
  • Regularly review and update cryptographic configurations to ensure they comply with the latest security standards.

3. Injection (OWASP A03:2021) #

Injection flaws, such as SQL, OS, or LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.

• Examples:

  • SQL Injection: An attacker appends malicious SQL code to a form input, allowing them to execute arbitrary queries on the database (e.g., SELECT * FROM users WHERE username = 'admin' --').
  • OS Command Injection: An attacker manipulates inputs to execute arbitrary operating system commands on the server (e.g., rm -rf /).
  • Cross-Site Scripting (XSS) or LDAP injection, where malicious scripts are injected into webpages viewed by other users.

• Implementation Tips:

  • Use parameterized queries or Object-Relational Mapping (ORM) frameworks to handle user input securely.
  • Validate and sanitize all inputs, regardless of their origin (user input, API, external systems), to ensure they meet expected formats and constraints.
  • Implement context-aware encoding (HTML, URL, SQL, etc.) for all user-supplied data before outputting it.

4. Insecure Design (OWASP A04:2021) #

Insecure design refers to flaws in the design phase of software development that can lead to security vulnerabilities.

• Examples:

  • Developing a web application without considering potential security threats (e.g., no threat modeling, lack of security requirements).
  • Failure to design adequate security controls for sensitive actions, such as not requiring authentication for accessing sensitive APIs.
  • Overly complex application logic that is difficult to secure and maintain.

• Implementation Tips:

  • Perform threat modeling early in the development process to identify potential threats and design mitigations.
  • Apply secure design patterns, such as “defense in depth,” to build multiple layers of security into the application.
  • Ensure security requirements are defined from the outset and integrated into the design process, not as an afterthought.

5. Security Misconfiguration (OWASP A05:2021) #

Security misconfiguration occurs when security settings are not defined, implemented, or maintained properly.

• Examples:

  • Default accounts and passwords left unchanged, allowing attackers to gain unauthorized access.
  • Unnecessary features enabled (e.g., verbose error messages, directory listing, sample applications, or admin interfaces exposed).
  • Using default or insecure settings in frameworks, libraries, or platforms.

• Implementation Tips:

  • Regularly review and harden all configurations for applications, servers, databases, and network devices.
  • Disable or remove unnecessary services, frameworks, and features that are not required for the application.
  • Implement a secure configuration management process, including regular audits and automated configuration checks.

6. Vulnerable and Outdated Components (OWASP A06:2021) #

This occurs when applications use libraries, frameworks, or other software modules with known vulnerabilities.

• Examples:

  • Using outdated versions of frameworks (e.g., a using a version of jQuery < 4 or Axios < 1.0.0 with known vulnerabilities).
  • Not applying patches to third-party components, such as content management systems (CMS), which may have critical security updates.
  • Relying on end-of-life (EOL) software that no longer receives security patches from the vendor.

• Implementation Tips:

  • Use software composition analysis tools to identify and manage known vulnerabilities in third-party components.
  • Establish a routine process for tracking and applying patches or updates to all components.
  • Replace outdated or unsupported components with maintained and secure alternatives.

7. Identification and Authentication Failures (OWASP A07:2021) #

These failures occur when authentication mechanisms are weak or improperly implemented, allowing attackers to gain unauthorized access.

• Examples:

  • Weak password policies, such as allowing simple or common passwords, or failing to enforce multi-factor authentication (MFA).
  • Exposing session IDs in URLs or not rotating session tokens upon login/logout.
  • Implementing custom authentication schemes that do not follow best practices, such as improper handling of tokens or cookies.

• Implementation Tips:

  • Enforce strong password policies, use MFA for critical operations, and secure session management practices.
  • Use secure, well-established authentication frameworks or libraries and avoid creating custom solutions unless necessary.
  • Regularly audit authentication mechanisms and implement security measures, such as account lockout and monitoring for brute-force attacks.

8. Software and Data Integrity Failures (OWASP A08:2021) #

These failures occur when an application relies on untrusted code or data that can be manipulated to compromise integrity.

• Examples:

  • Unsigned or unvalidated software updates that could allow attackers to distribute malicious code.
  • Insecure deserialization of data from untrusted sources, leading to remote code execution or other attacks.
  • Lack of verification for data integrity, allowing tampering or corruption of data during transit or storage.

• Implementation Tips:

  • Sign and verify all software updates and packages to ensure they have not been tampered with.
  • Avoid deserializing data from untrusted sources, or apply strict checks to validate the integrity of serialized data.
  • Implement checksums, digital signatures, and other integrity checks for critical data, especially when it is transmitted over networks.

9. Security Logging and Monitoring Failures (OWASP A09:2021) #

This occurs when applications lack sufficient logging and monitoring capabilities to detect and respond to security incidents.

• Examples:

  • Insufficient logging of key security events, such as failed login attempts, privilege changes, or data access violations. Read more about logging
  • Failure to monitor logs in real-time, delaying incident detection and response.
  • Logs that are not protected against tampering or deletion by attackers.

• Implementation Tips:

  • Implement comprehensive logging for all critical actions and potential security incidents, ensuring logs are centralized and monitored in real-time.
  • Use automated alerting and correlation tools to identify patterns of suspicious behavior and trigger incident response.
  • Ensure that logs are protected with access controls, encryption, and backup mechanisms to prevent tampering.

10. Server-Side Request Forgery (SSRF) (OWASP A10:2021) #

SSRF vulnerabilities occur when an attacker can manipulate server-side requests to access or interact with internal services.

• Examples:

  • An attacker crafting a URL that tricks the server into accessing internal resources, such as metadata services or internal APIs, potentially exposing sensitive data.
  • An SSRF attack that leverages a server-side request to perform port scanning, exploit internal services, or bypass firewalls.

• Implementation Tips:

  • Enforce strict input validation and sanitization for all incoming requests, especially those that trigger server-side requests.
  • Restrict outbound network access from servers to prevent unauthorized connections to internal or sensitive external resources.
  • Use a firewall, allow-list policies, or network segmentation to limit access to internal services.

Code Smart, Code Safe #

At Stacc, secure coding is not just a best practice; it’s a core responsibility embedded in every stage of our Software Development Lifecycle (SDLC). By integrating security principles from the outset, we ensure that our applications are resilient against vulnerabilities, protecting both our users and our reputation. Every developer plays a crucial role in maintaining this standard—writing code that is both innovative and fortified against threats.

Actionable security measures for developers and teams #

To ensure secure coding practices are consistently applied across Stacc, developers are expected to adhere to the following actionable measures:

• Shift left: Security must be integrated early in the SDLC. Tooling helping this is implemented by each team independently to accommodate their unique needs. These may include SAST (Static Application Security Testing) tools, DAST (Dynamic Application Security Testing) tools, and code reviews.
• Continuous training: Developers must stay current with the latest security threats and mitigation techniques through regular training sessions. Sessions like CodeCraft are conducted at the onboarding level, and OWASP Top Ten training is provided to all employees on a regular basis.
• Automated testing: Utilize automated tools for vulnerability scanning and dependency checking as part of the continuous integration and deployment (CI/CD) pipeline. Tools like Snyk are used to scan for vulnerabilities in the codebase both at build time and will alert developers to potential issues later in the lifecycle.
• Threat modeling: Conduct threat modeling exercises to understand potential vulnerabilities and design appropriate defenses.
• Peer reviews: Mandatory peer code reviews are conducted for all code changes destined for production, ensuring that security vulnerabilities are identified and addressed promptly. These are commonly conducted in the form of a pull request review. Risks are also identified and addressed in the review.
• Documentation: Maintain comprehensive and up-to-date documentation for all security processes, configurations, and incident response procedures.
• Incident response plan: Each team must have a clear, actionable incident response plan, regularly tested and updated to ensure readiness in the event of a security incident.

Harmonizing security practices #

To harmonize secure coding practices, Stacc will ensure the following:

• Regular risk assessments (ISO 27001): Each team must conduct risk assessments regularly and as part of any significant change to align with the evolving threat landscape.
• Employee training (ISO 27001): Stacc will ensure all employees, especially developers, receive regular training on the OWASP Top Ten and other relevant security threats.
• Ongoing audits (ISO 27001): Stacc will conduct regular security audits to verify compliance with ISO 27001 standards and internal policies, ensuring that security practices are not only compliant on paper but effective in practice.
• Continuous feedback loop: Stacc will maintain a continuous feedback loop to adapt security practices in response to changes in the threat landscape and updates to ISO 27001 and OWASP guidelines.