Principles for secure software

Secure software involves both the developer and end user

Basic assumption of the Alliance is that security of software is not only a technical issue, but also an organizational. Security of Software requires involvement of the developer and the user of software. When is software secure enough for application in a specific context?

If software security is measurable, controllable and demonstrable, software users can consciously make decisions (based on the interests of business and organization processes weighted against the risks of software) and, moreover, take measures to control risks. The buyer of software must be aware that software contains or may contain inherent insecurities and that he must set up processes to control the risks of insecure software. The provider of software often plays an important role in those control processes.

Secure software needs attention during the lifecycle

Software Security needs attention during the complete lifecycle. Threats and risks change continuously. Processes are required to manage these changes. Developers of software and organizations of software are both involved in these processes to make and keep software secure.

Secure software is the basis for trust in ICT

Software is everywhere. The Cybersecurity Act states therefore that software security is elementary for cybersecurity. By making software security measurable, manageable and controllable, the Secure Software Alliance allows parties using software to take responsibility for the software they use in a specific context.

Standard

The Secure Software Framework (SSF) from SSA defines a standard to help to improve secure software lifecycle management, including software development:

  • For development teams, the framework helps to implement secure software development practices.
  • For auditors, the framework gives criteria to evaluate the security of software.
  • For purchasers, the framework makes the software’s security properties visible.

SSA is an non-profit initiative: participants are invited to join and participate in the implementation of the framework and to gain experience.

Security of software is essential

Important stakeholders are:

Board and directors

The compliance requirements for organizations include often responsibility for the security of IT and therefore of the software. This means that organizations have to make decisions about the management of the risks inherent to the use of IT. The Secure Software Framework from SSA makes it possible to decide about the risks.

Small and medium enterprises (SME)

May suffer from the impact of vulnerabilities of software. When they become victim of attacks the costs can be high. Often SME’s are part of value chains in vital sectors, making the impact of vulnerabilities even higher.

Software developers

Digital security must be part of the culture of an organization. That is why it is necessary to make security an essential part of the entire product life cycle of software. Safe boundary conditions must be included from start to finish within the Agile / DevOps development process. SSA developed and maintains the SSF framework for this with which security is addressed within the entire digital software landscape of companies.

Consumers

Consumers have more rights and exercises their rights more effectively. They ask questions about the security of services and their data. Organizations should be able to answer these questions to enhance trust in their services.

Software development phases

SSA phases

The Secure Software Framework is divided in the four phases for software development:

1. Context phase

In the context phase, the security requirements and security assumptions are determined. The context defines what `secure’ means for the software system. Using a systematic method, it is possible to check for missing security requirements.

2. Threats phase

Based on the above context, potential security problems (threats) are identified. Threats originate from the application’s behavior, its architecture and its implementation.

3. Implementation phase

For every threat, a countermeasure (mitigation) is created. Because threats are gathered systematically using a threat library, missing threats can be detected. Implementation The use of a secure coding standard helps to prevent security issues at the implementation level. A systematic code audit can check if the software is securely implemented.

4. Verification phase

For every mitigation, a verification is described. During development, these verifications provide feedback to the development team. The evaluation of these verifications gives an extra assurance that the mitigations are securely implemented.