Page Comparison

The following requirements relate to security testing activities for all applications developed within

1. General requirements:

   1. Correct and complete implementation of security & security-relevant requirements and changes MUST be verified with suitable security tests.

   2. Where possible, security tests SHOULD be executed automatically and continuously (e.g. within CI and CD pipelines) and as early as possible within the development process (fail fast principle).

   3. Test data MUST not contain confidential or personal (PII data) references.

   4. The execution of security tests MUST NOT be affected by perimetric security systems (e.g. a web application firewall).

2. Defect tracking:

   1. Security defects MUST be tracked in defect tracking system and provide relevant meta information (e.g. criticality rating, CVSS score etc.).

   2. Open security defects SHOULD be regularly checked for relevance and possible quick wins.

   3. For applications with assurance class >= [HIGH], security risks MUST also tracked in defect tracking system.

3. Utilize automated security testing tools:

   1. Applications MUST be automatically analyzed with security code scanning tools (SAST or IAST) in order to identify implementation vulnerabilities in source and program code as early as possible.

   2. Applications MUST be automatically analyzed with SCA (Software Composition Analysis) tools for any known vulnerabilities in 3^rd party dependencies.

   3. Docker images used in the target production environment MUST be automatically scanned for security issues.

   4. Security-relevant configuration MUST be automatically scanned for security issues.

   5. For applications with assurance class >= [HIGH] Security testing tools MUST automatically enforce security requirements and security testing policies within the build process as specified at 5. Security within Software Development Process.

   6. Applications with assurance class [VERY HIGH] SHOULD be periodically tested for denial-of-service attackability.

4. Custom security tests & developer tests:

   1. Security tests of implemented security requirements and security controls (e.g. authentication or access controls) SHOULD be implemented, executed, preferably in an automatically and continuously way.

   2. Developer and system acceptance testing SHOULD include testing for functional (security controls) and non-functional^[1] security requirements.

   3. Abuse cases SHOULD be created & tested for critical business security aspects in applications with assurance class >= [HIGH].

5. Pentests:

   1. Applications MUST be verified by penetration tests according to the pentesting policy bellow. Penetration tests SHOULD be carried out within environments that are close to production environments (e.g. on integration systems).

   2. After an severe vulnerability has been fixed, a retest should be executed, ideally by the same tester, in order to verify the correct implementation of the fix.

...