Long gone are the days when software was tested by “click testers” who clicked their way through an application using comprehensive test specifications, and in particular, who used extreme parameters to test edge cases (i.e., borderline cases). Software testing has become an independent discipline in the field of software development.
Most edge case testing is now obsolete. Today, security testing primarily addresses attack vectors resulting from manual testing and an insufficiently agile mindset which hackers seek to exploit to cause damage. This article will look at how systems can be protected against such attacks, and how new concepts such as DevSecOps and a correspondingly adapted systems development life cycle (SDLC) can help. With DevSecOps, security is an essential part of software development, from the first line of code to the final product.
One alternative to DevSecOps is Scrum. In order to develop secure software, you need an agile SDLC with the ability to react quickly and flexibly to external circumstances, one that lets you say: “Security? That’s baked in!”.
Changing mindsets
The automation of processes is one pillar that supports the foundation of the SDLC. However, to build a DevSecOps culture, you need more than just this pillar. It also takes a mindset shift allowing for new ideas to be embraced and integrated into a continuous learning process. The goal is steady and incremental improvement with a willingness to try new things.
Acceptance test-driven development (ATDD) can help with this. ATDD is an extension of agile methods based on “test-driven development” (TDD), which was first introduced by Kent Beck in 2023. The idea is to first define and write test cases for a problem, then implement a solution based on these cases. Initially, it doesn't matter whether or not the respective cases involve security. With ATDD, product owners specify acceptance test cases that developers can use when writing their code. Unlike TDD, which developers use on the basis of unit tests (lowest level of testing), ATDD also includes acceptance tests. These tests can be defined in Gherkin, for example. Gherkin is a programming language that can be used to write test cases for the testing tool Cucumber as part of ATDD. Among other things, Cucumber allows for the automatic execution of test cases, both in desktop browsers and on mobile devices. In theory, ATDD can serve as the basis for the “Three Amigos” approach. With this approach, three coworkers with different points of view (e.g., business analysts, developers, and testers) meet during the development process to discuss ways to eliminate potential ambiguities early on and thereby also prevent security risks during the SDLC.
The Tiny Tools toolbox for retrospectives
As mentioned above, a modern DevSecOps strategy that focuses on software security consists of more than just technical solutions. One such technical solution includes automated testing, provided (for example) by OWASP Top 10, which can automatically check the top 10 threats to a piece of software and determine whether the source code presents vulnerabilities. On the other hand, there are “retrospectives,” a “social” solution that helps change mindsets and thereby improves security. Retrospectives are a crucial part of agile processes that can make use of an entire toolbox of methods to strengthen the DevSecOps approach. During retrospectives, agile teams consider how processes can be optimized and discuss the reasons why certain sprints hit the wall and what the team can learn from such sprints.
Tiny Tools, a set of small and compact tools, can support the team during retrospectives and help them strengthen their agile mindset. These tools arose during development cooperation (formerly known as development aid) in countries of the “Global South.” Among other things, the “Life Line”/“Quality of Life Curve” examines how quality assurance has developed in a team over a period of time, and what can be learned from it. Team members are asked how they perceive the development of quality assurance. Events having a major impact (e.g., serious errors) can be considered as a starting point. During the retrospective, participants can describe both positive and negative events. The events of the selected period are then evaluated with the help of a “life line.” A rising curve is rated as positive, while a dipping curve is rated as negative.
Strategic planning of tests
“Road journey” diagrams help identify a group’s individual goals and determine how current development projects fit with these goals. The team members create a roadmap to describe the changes in the team over a period of time. This road can be straight or winding, and go uphill or downhill. Symbols such as bridges and other key elements can also be used. A road journey is an ideal tool for helping teams test more strategically.
“Impact maps” are used to define the various influences in a project which have led to certain impacts. The team can ask questions (how, why, etc.) to determine changes, as well as the reasons why such changes arose. Impact maps are particularly effective during planning phases and situation analyses after problems have occurred and the team wants to determine the cause and origin of the “accident.”
A stakeholder analysis is a tool to identify all the stakeholders in an ecosystem and to identify the goals and problems of each participant. During this analysis, the emphasis is placed on the group within a project that would benefit from an improved DevSecOps strategy. This tool can be used to assist with the development of such a strategy before the strategy is presented, as it can help identify the challenges which may emerge.
Proportional piling is primarily used to visualize effects by way of quantities (“piles”). During a software project, this can involve the creation of piles to represent the various influences from other teams involved in the project and other factors that affect the teams in charge. Self-assessment involves asking key questions to assess a team’s agility. The larger the pile, the greater the agility. Another concrete example involves using this method to determine the impact of a measure on a project.
Automation: A key pillar for a quality gate
In order to reinforce the mindset shift achieved via the use of Tiny Tools, a DevSecOps strategy must be supported by a second pillar: automation. Automation is an extensive field. Certain testing frameworks are designed for end-to-end (E2E) tests, while others specialize in testing REST interfaces, which describe the communication in a web application at the level of the network. There are also testing frameworks that do both.
First released in 2020, Playwright is a new testing framework. Developed by Microsoft, this framework is specially designed for E2E testing, but can also test REST interfaces. Cypress, the leading framework which has been around for much longer than Playwright, has great difficulty doing both.
Playwright incorporates certain aspects of the “Three Amigos” approach. It can also work with Gherkin, allowing the team of business analysts, developers, and testers to apply the ATDD approach directly. What’s more, Playwright makes it possible to automatically generate E2E tests with a tool test code entered by users clicking through the application (like manual testers), with the difference being that source code is generated which can be incorporated into the project and linked with Gherkin.
Since Playwright can be used “headless” (i.e., without opening a browser) in a build pipeline (such as Jenkins), extensive E2E testing can be done before the software is created. The pipeline can also be used to check the vulnerabilities of the software with the OWASP Top 10 Dependency Check.
A secure gateway to the world
In order to build a gateway (or quality gate), a cornerstone is needed that connects the mindset and automation pillars. In his talk at GDC 2023, Seth Coster presented a model for stress-free game development that can benefit the entire IT industry. This approach is based on an SDLC, which in turn is based on learning and feedback loops.
Figure 2 Modified SDLC
The approach relies mainly on the elimination of waste from manual work and moving targets (for example) in the SDLC which loop through the system and clog the project with bottlenecks. It is therefore vital that work packages always flow in one direction (from development to operations to the customer), and that feedback be exchanged to prevent extra loops.
With the approach described in this article, which uses retrospectives with Tiny Tools and automation with Playwright and OWASP Top 10 Dependency Checks in a build pipeline, a secure quality gate can be built through which software can be safely delivered to customers.
Would you like to learn more about how our in|sure software can help you master the challenges of digitalization? Then get in touch with our expert, Karsten Schmitt, head of business development.