In enterprise software development, the quality criterion of security is becoming increasingly important. However, traditional approaches, in which security is only considered at the end of milestones through security tests, often lead to significant impairments in terms of time and budget. As a result, software security is often perceived as a brake. However, by consistently integrating security aspects into the entire development process, security costs can be made calculable and security quality assurance can be ensured. The result: software applications can be transferred to production securely and efficiently.
Short & concise
- In enterprise software development, the quality criterion of security is becoming increasingly important.
- The earlier security vulnerabilities are discovered in the development process, the easier and more cost-effective it is to rectify them.
- With the lean application security approach, the effort required for security can be flexibly adapted to the needs of the project. Instead of the motto “As much security as possible”, the credo “As much security as necessary” applies.
- Security requirements should be integrated into the development cycle right from the start as part of the Definition of Done.
Cyber attacks have been part of everyday life for years and have increased significantly in recent times. For this reason, the definition of appropriate security standards is one of the indispensable necessities within software development. In reality, however, development teams repeatedly fail to fulfil the desired security requirements on time and within budget. This failure is by no means accidental. Rather, the usual workflow in day-to-day software development ensures that the costs of security remain in the dark for a long time.
Agile frameworks such as Scrum do not usually provide for the role of the security expert. As a result, it is often common practice in agile projects not to iteratively improve the security of the developed software during development, but to analyse the resulting product for security vulnerabilities in a final analysis shortly before go-live. This approach often ends in a rude awakening when this analysis – to the surprise of the project – uncovers serious security flaws.
Security quality assurance cannot be checked retrospectively
In a situation like this, there are only two options for action, which are, however, associated with considerable risks. The first option is to consciously accept the risk associated with the security gaps and carry out the go-live as planned. In this case, the schedule can be adhered to – but the risk of an attacker also discovering and exploiting the security gaps is incalculable. In addition to the concrete damage that an attacker can cause, the image of the software operator is also at stake if a successful attack is publicised and sensitive customer data may even have been stolen.
Alternatively, organisations can decide to postpone going live in order to close the security gaps at a later date. However, this solution is also problematic: on the one hand, a delayed go-live can also lead to reputational damage – for example, if the go-live was announced in advance on a specific date and customers or partners relied on the promised date. On the other hand, the estimated budget can quickly get out of hand if improvements have to be made after the actual development process has been completed.
The discrepancy described between the time of occurrence and detection of errors and their impact on the budget was already demonstrated by Capers Jones in his 1996 book “Applied Software Measurement” and illustrated in an informative and much-cited infographic:
The accuracy of the infographic has not changed in the nearly thirty years since its publication. However, it is not only time and budget constraints that are at stake in the traditional handling of security issues in the software development process: In the course of remedial work, it may turn out that the architecture of the affected application makes it impossible to completely eliminate the security flaws. In such a case, the entire project could even be jeopardised.
Lean application security makes security in enterprise software scalable
As the above scenarios show, the strategy of relying on a one-off security check at the end of the development process harbours major risks in terms of time and budget planning. An alternative approach is to address the issue of security throughout the development process – for example, by integrating a security consultant into the project team to ensure that security is considered as an integral part of the system and software architecture from the outset and implemented iteratively in line with the agile project approach.
However, many organisations shy away from the step of integrating a security expert into the project team. There are two reasons for this reluctance: Firstly, many decision-makers fear that dealing with security issues during development will significantly increase the complexity of the already complex software development process. Secondly, it is often assumed that the involvement of an expert will lead to excessive security measures – to the detriment of other important aspects such as usability.
However, these fears fail to recognise that software development projects are very individual and therefore the scope of the necessary security measures can vary greatly. The lean application security approach recognises this, according to which the security effort should be flexibly adapted to the needs of the project. Instead of the motto “As much security as possible”, the credo “As much security as necessary” applies. This guideline should also be reflected in the organisation of the security consultant’s role: They can act both as a fully-fledged project member who accompanies the team throughout the entire development process and as an on-call consultant who is only called in when necessary. The involvement of the security advisor can be freely defined between these two extreme variants.
The security advisor takes on an advisory role, particularly if they are not part of the organisation themselves, but are provided by an external service provider. In addition to the technical “basic protection” (keyword “security by design”), the task of the security advisor with regard to the optimisation of business processes in this case is to show the decision-makers options for specific issues and to explain their advantages and disadvantages. On this basis, the project manager of the advised organisation, who has more detailed knowledge of the technical processes than the security advisor, can then make a competent decision. This means that the organisation ultimately retains control in this sensitive area.
Integrating security does not mean restructuring processes
It is no coincidence that agile methods have become established in many areas of software development. They give teams plenty of room for flexibility, make undesirable developments quickly visible and correctable through regular iteration cycles and increase efficiency. In order not to jeopardise this efficiency, changes to the established processes of agile software development should only be made very cautiously.
This also applies to the integration of security into the development process. Accordingly, classic security procedures must be adapted to agile processes – and not the other way round. To give an example: Establishing a fixed test phase including mandatory code reviews and penetration tests is not recommended as part of a sprint. The risk of creating a security bottleneck that slows down the speed of agile software development would be too great.
Instead, security requirements should not only be checked after the development of a functionality, but should be integrated into the development cycle from the outset as part of the Definition of Done – with corresponding effects on the ticket workflow: the Security Advisor can be consulted as early as the ticket formulation stage in order to include important security requirements in the ticket or to categorise a ticket as not security-relevant.
The results of the subsequent development work are then tested automatically to ensure a quick turnaround. The early integration of automated security tests shifts the discovery of vulnerabilities forward on the timeline and is therefore also referred to as “shift left”. In Capers Jones’ illustration, such integration would be represented by a shift of the yellow curve and in particular its maximum to the left parallel to the blue curve.
In the best case scenario, the integration of such tests hardly causes any significant effort on the part of the development team. The prerequisite for this is that the configuration and calling of the corresponding tools as well as the testing, evaluation and further processing of the identified vulnerabilities work without special expertise and essentially with the knowledge of the developers and DevOps. Security testing platforms such as mgm ATLAS are predestined for this.
Manual code reviews and penetration tests are only carried out when necessary. In many cases, the Security Advisor can also describe in the ticket which steps are necessary to test the desired security feature. In this way, quality assurance employees can test the implementation of such security requirements without having to be experts in this field themselves.
Even if the agile project approach is only cautiously adapted by integrating security measures into the development process, it is crucial that the changes are supported by the entire team and do not degenerate into a one-man show by the security advisor. Initial training sessions have proven to be a very effective way of informing the team about the benefits of security during development and creating the necessary awareness, and can make a significant contribution to the success of a project. A common vocabulary should also be developed in these training sessions in order to avoid misunderstandings between the security advisor and the team at a later date. Decision-makers outside the actual team should also be sensitised to the topic through awareness seminars in order to clarify the benefits of security and avoid an energy-sapping “battle against windmills”. After all, it is precisely these decision-makers who have to repeatedly weigh up the various alternatives with regard to security requirements – decisions that they may later have to justify within the organisation.
Conclusion
Against the background of the examples mentioned, it cannot be denied that the strategy of implementing security requirements during development initially increases the time and budget expenditure within software development – slightly in relation to the overall development effort. After all, with the Security Advisor, not only does an additional role have to be installed within the framework, but the processes also have to be minimally expanded in order to make the topic an integral part of the development process. The acquisition of tools for automated security tests also initially incurs costs.
However, the initial additional expense buys a company the elimination of central pain points, which quickly amortises them. The likelihood of a go-live being delayed by serious security flaws and thus exceeding the budget is significantly reduced by involving a security expert in the development process and automated tests during development. By significantly reducing the possibility of delays and incalculable risks and replacing them with calculable variables such as the costs of a security advisor and, if necessary, licence costs, the cost of security no longer has to be estimated according to the principle of hope. Instead, it becomes largely calculable in advance.
