Secure Software Development

Having secure software is at the heart of a SaaS solution. Best practices of secure software development suggest integrating security aspects into each phase of the software development lifecycle. This topic describes how security aspects are integrated.

Design

The secure design stage involves six security principles to follow:

Least privilege

Software architecture should allow minimal user privileges for normal functioning.

Privilege separation.

Specific actions in software (e.g., create, delete or modify certain properties) should be allowed to a limited number of users with higher privileges.

Complete mediation

Every user access to the software should be checked for authority. That decreases the chances of privilege escalation for a user with limited rights.

Multiple security layers

Applying this principle, you’ll eliminate the threat of a single point of security failure that will compromise the entire software. It’s simple math: the more defense layers your software has, the less are chances for a hacker to exploit its vulnerabilities.

Secure failure

In case your software ceases to operate, it should fail to a secure state. Although the software is not available anymore, still it should preserve confidentiality and integrity. So, make sure you’ve designed secure defaults that deny access, undo all the changes and restore the system to a secure state in case of emergency.

User-friendly security

Software design should incorporate security aspects in a way that doesn’t hinder UX. If security mechanisms in the software are obtrusive, users are likely to turn them off.

Development

Best practices of secure development defend software against high-risk vulnerabilities, including OWASP (Open Web Application Security Project) top 10. As a result, there will be no need in fixing such vulnerabilities later in the software life cycle, which decreases customer’s overhead and remediation costs.

OWASP, one of the most authoritative organizations in software security, provides a comprehensive checklist for secure coding practices. Use this source if you’re looking for exact requirements for secure software development, rather than for the descriptions of exploits.

Code reviews

All code will be reviewed by at least 2 others as part of the Pull Request process. Special attention is needed for the security of the delivered software. Making the Pull Requests as small as possible will help keeping the changes understandable and will lower the changes of (security) issues.

Secrets

Secrets needed in the execution or deployment of software are always stored in a vault, automatically retrieved in the deployment pipeline, obfuscating credentials from developers.

Continuous Integration

Is used to have a fully automated deployment process. As this involves automated testing and fully automated pipelines, the use of Continuous Integration is mandatory, minimizing manual intervention.

Framework security patches and updates

Using Continuous Integration pipelines should also involve automatic updating frameworks with security updates.

Scheduled Security Reviews

Every 3 months, security reviews should be scheduled for active products.

Although secure coding practices mentioned above substantially decrease the number of software vulnerabilities, an additional layer of defence won’t go amiss. The code review stage should ensure the software security before it enters the production stage, where fixing vulnerabilities will cost a bundle.

Check OWASP’s security code review guide to understand the mechanics of reviewing code for certain vulnerabilities, and get the guidance on how to structure and execute the effort.

These reviews should involve analysts, the Data Protection Officer and other stakeholders and are focussed on a functional view on security: what are market requirements, is the solution user-friendly, etc.

Scheduled Security retro’s

Every 3 months, each active product should have a security retro with the following subjects:

• Collect Team feedback on security
• Collect DPO feedback on security
• Create a list of potential threads
• Create improvements in the work process incorporating security
• Create a list of security improvements to work on the next 3 months
• Create an improvement schedule for the next 3 months