It is simply not enough to address security only at the end of the development lifecycle, for instance by comissioning pentests. There are a couple of reasons for that: (1) Costs for fixing a security issue are rapidly increasing the later it is done within an application lifecycle. (2) The architecture builds the fundament of a secure application. If an application is build upon a insecure fundament, it will never reach a really high level of security.
Therefore, security needs to be adressed troughout the whole software development lifecycle. In this context we often speak about building a Secure SDLC or Secure Development Lifecycle (SDL), that integrates security processes, practices and requirements into a Software Development Lifecycle (SDLC). Here is a generic high-level example of how this could look like:
This is of course rather simplified and usually requires a lot of aspects to be concideres to work propably throughout the whole organization and different ways by which software is creates or contracted. Implementing a Secure SDLC for agile development like Scrum or Kanban works as wel. Although it may look a bit different it can by made being compliant to the same requirements as a Secure SDLC for a waterfall development.