Secure coding

Software under development, testing and production is run in differentiated technical environments in order to ensure the quality of development work in an environment that adapts to the production environment and, on the other hand, the production environment is not disturbed by unfinished development.

Sensitive or personal data of users is not copied and used in a development environment.

General rules for reviewing, approving and publishing the code have been defined and enforced.

The rules may include e.g. the following things:

• the generated code has been validated against the general safe development guidelines of the OWASP Framework
• the code has been reviewed by at least two people
• the changes have been approved by a designated, authorized user prior to publication
• the system documentation has been updated before release
• the time of publication of the changes has been chosen in accordance with the given instructions in order to minimize disruption to business processes
• the instructions needed by users have been updated before the code is released

The rules are intended to manage the risks associated with the release of new program code.

The general rules for secure development work have been drawn up and approved by the development managers. The implementation of the rules is monitored in software development in the organization and the rules are reviewed at least yearly.

The safe development policy may include e.g. the following things:

• safety requirements of the development environment
• instructions for secure coding of the programming languages used
• safety requirements at the design stage of properties or projects
• secure software repositories
• version control security requirements
• the skills required from developers to avoid, discover and fix vulnerabilities
• compliance with secure coding standards

Compliance with the rules of secure development may also be required of key partners.

Even when development is outsourced, we remain responsible for complying with appropriate laws and verifying the effectiveness of security controls.

We have defined the procedures that we monitor and follow throughout the outsourcing chain.Practices may include e.g. the following things:

• policies for reviewing and approving generated code
• evidence of testing activities performed by the partner
• communication practices
• contractual rights to audit the development process and management tools
• documentation requirements for code generation

The organization regularly conducts a vulnerability scan, which searches for vulnerabilities found on computers, workstations, mobile devices, networks or applications. It is important to scan even after significant changes.

It should be noted that vulnerable source code can be from operating system software, server applications, user applications, as well as from the firmware application as well as from drivers, BIOS and separate management interfaces (e.g. iLo , iDrac). In addition to software errors, vulnerabilities occur from configuration errors and old practices, such as the use of outdated encryption algorithms.

Vulnerabilities in third-party or open source libraries must be monitored, scanned, and reported in the same style as other vulnerabilities.

The organization must define policies to identify required updates in applications that use external libraries. Surveillance scans can be automated with specialized tools.

It also makes sense for an organization to monitor overall communication about vulnerabilities.