Secure Development

A documented risk analysis is available for each third-party app used by the application. Third party apps and libraries are tracked for vulnerabilities and security updates as part of the main app.

The system scans attachments, uploads and links for malware and filters content identified as harmful by these scans.

The application has taken application level steps to prevent Denial of Service attacks such as caching where possible, rate limiting and designing functionality to be non-blocking. This includes protecting API endpoints against executing requests that could lead to DoS, limiting upload field data size and locking out users through reset functionality.

Description Mobile Applications use certificate pinning to prevent MitM attacks on apps and Open WiFi. Mobile applications have protections for the binaries that users can download. Mobile apps preferably store information encrypted and containerised. Sensitive information must be stored server-side unless specifically needed for functioning of the application.

Web applications have taken all appropriate measure to protect against OWASP top 10 Web Application vulnerabilities: https://owasp.org/www-project-top-ten/

All variable information that gets sent by a client is filtered and sanitized before being processed in the application. The same applies to user-selected output that is presented back to users. This avoids any unintentional side-effect of processed data.

Appropriate secrets management is applied to confidential information needed to develop and deliver the service. No hardcoded credentials and configurations are present in source code, only in separate configuration files with appropriate security protections. No sensitive information can be found in versioning information and older releases in version management systems. Configuration is stored in environment variables or in versioned scripts that generate the configuration based on user input.

Major changes and/or migrations that could have potential impact on the availability of the IT service have a rollback procedure and a step-by-step plan for the change documented beforehand and approved by the relevant change boards. This rollback procedure can be requested.

No production information is exposed or reused in environments other than for acceptance testing. This includes production data (also not pseudonymised), API keys, credentials and production server hostnames.

Description At a minimum there are distinct environments for acceptance and production. Where development activities take place, at least one separate environment for development exists. The environments are clearly distinguishable (for example through a different colour scheme). Privileged Access to the production infrastructure is completely separated from privileged access to the other environments. Authentication to non-production environments does not take place through the production IdP. The acceptance environment must represent the production environment as closely as possible with the exception of not being publicly available. Before going into production, any change must always be tested in the acceptance environment.