M.10) Involve PSR in product development

Category:        Product development

Responsible:   PSR

Effort:              no initial effort, but periodic with every sprint

Based on:       BSI IT Grundschutz M 3.97

The person or team responsible for product security should be involved during the whole product development life cycle:

  • Requirements engineering and analysis
    • The PSR should specify security requirements, where each requirement needs to be specific and testable. Some security requirements might be general ones which have to be taken into account by every developer (like sanitization of user input to prevent injection attacks). Those requirements need to be included into the programming guidelines, but the actual implementation of them also needs to be reviewed and/or tested somehow.
    • Evaluate each security requirement in terms of cost (money, usability, complexity, flexibility, speed, etc.) with other engineers and the CTO. Afterwards decide which requirements are mandatory, which ones can be opted out and which ones can be opted in later. This ensures that the PSR doesn’t define measures and requirements which are not economically feasible.
  • System and software architectural design
    • Authentication and authorization mechanisms are central parts of many software products. But there are also other security considerations which are important for the architecture. Therefore the product security engineer should take part in designing the system and software architecture.
    • In web development it is state of the art to build new projects upon proven and well tested frameworks. This is a risk from the information security point of view.
    • For those reasons the product security engineer should be involved in such decisions from the very first day.
  • Detailed software design
    • The product security engineer should be part of design reviews
  • Implementation
    • The PSR should be part of code reviews
    • The PSR should organize pair programming sessions with other developers to check their security knowledge and to increase his knowledge about the system
  • Verification and (regression) testing
    • The PSR should write or require regression tests which emphasize on finding software vulnerabilities. These should include unit (e.g. test of a password hash algorithm) and integration tests (e.g. test if it’s possible to bypass authentication or authorization mechanisms).
    • Also he/she should periodically perform classic penetration tests where he/she tries to find vulnerabilities and exploit the software
    • The PSR should establish automated penetration tests
  • Deployment
    • Developers of modern software products use agile methods like Scrum together with concepts like continuous integration, continuous delivery and continuous deployment to deliver new software features faster to the customers. The delivery intervals can be periodically, for example each night (nightly builds), in weekly cycles or even with every new developed feature. This is also important from the security aspect, because:
      • Such concepts require a very high degree of reliable/stable regression tests. Otherwise it would be impossible to guarantee that the new deployed software is still functional and secure. Because if the software is deployed on a daily basis or even more often, it’s impossible to perform all those tests manually. Even if the tests are not stable and have a high false-negative rate there would already be problems because of the necessary manual interaction.
      • If software can be updated on a daily basis, it’s easy to deploy security bug fixes, without even bothering users.
  • Maintenance
    • Maintenance is especially relevant for products which are delivered to the customer and can’t be easily updated. In this case different versions of the product are in field. This might be the case for standalone software applications, embedded systems software or mobile app which are different depending on the operating system (OS) and the version of the OS. In these cases it can get hard to fix a critical security flaw, because it is necessary to update many different versions in the field. The overview and decision which versions should be updated has to be made by the product security engineer or a person from the management (CISO, CTO).
    • If the product gets re-designed because of a new major release, new features, etc., the security development cycle needs to be restarted and overthought.

But also supporting tasks have to be taken into consideration, like

  • All kinds of reviews (e.g. design and peer code reviews)
  • Creation of guidelines and method descriptions



The information contained in this website is for general information purposes only. You can find more information about the accuracy of the information on the disclaimer and terms and conditions pages.