Source: Pixabay
In the software world today, many teams are adopting the culture of DevOps and DevSecOps. The modus operandi of Dev(Sec)Ops is to have Continuous Testing done as early as possible in the software development lifecycle before it reaches production – this is the concept of “shifting left” in terms of DevOps. This can be realized when teams are writing code using an approach known as Test-Driven Development where the test cases are written (in code) before the actual feature. This is helpful to define the scope and the features that will eventually fit into. It gives developers a target to aim for rather than thinking on-the-fly about what the features should actually be. The developers, in this case, are also the testers, and may even be the authors of test cases. There is no limit to the scope or test cases that one can write - it can range from testing the application’s security, feature, error handling, performance, etc.
The purpose of performing tests is to collect quality measurements of the code, so when it passes a certain quality, it moves on to the next stage. These measurements should also be collected and presented in a way that makes sense to both the developers and managers so that code quality can be determined at a quick glance. Plus, to perform tests at scale, automation is key. A repeatable test process, coupled with a tool that can easily integrate into a current ecosystem, is often preferred.
Security Advantages of Open Source in Testing
Leveraging on open source knowledge and tools to achieve the goals of development and testing is clearly an advantageous step for the developers. Open source pools the knowledge of many with vastly different experiences to achieve a common objective. The open source knowledge is usually co-created for developers by developers because there were no prior definition or knowledge base on a certain topic. What open source provides for is a channel to report or to contribute, and the topic of security is one that makes sense to open source. When someone reports a zero-day vulnerability, this knowledge is valuable to the whole community and will in turn drive efforts to find the fix as soon as possible, thus improving quality of the project.
Role Models of Open Source Security
The RSA algorithm, as an example for open source security implementation, was publicly derived after the research and scrutiny of many mathematics and computer experts, which has now become an industry standard and implemented widely in many systems as the go-to encryption algorithm.
The Common Vulnerabilities and Exposures and Exploit-DB are open source knowledge databases which security specialists keep abreast for the latest security data. These open source security vulnerabilities and intelligence are the bread and butter by of security professionals. But what's more valuable today is what has been built on top of these databases - a security service, complete with a tool, that feeds on existing security databases so that security vulnerability detection and remediation can be as quickly and seamlessly as possible.
Open Source Testing Tools
In the Dev(Sec)Ops context, developers are encouraged or tasked to test both the application and the infrastructure it runs on, hence testing can be grouped broadly into the above two categories respectively.
This (horizontal) flow diagram helps to visualize some of the open source tools used in a CICD pipeline during the software lifecycle that focuses on application security testing. Also, a tool like OWASP ZAP can also test for the dynamic behavior of a web application after or during deployment to benchmark it against the OWASP Top Ten Most Critical Web Application Security Risks.
This (vertical) diagram illustrates testing of the infrastructure where a testing tool “punches through” the full stack.
Netflix’s Simian Army penetrates through and tears down the whole infrastructure stack and tests for outcomes such as high availability and resiliency of the infrastructure. This army has since inspired many derivatives of monkeys to test for different infrastructure resiliency like the WazMonkey, KubeMonkey, and MonkeyOps.
Mapping Open Source Tools to DevOps Practices and Values
Open source tools are free to use and have a low financial barrier to entry. Secondly, they are usually a product of itself, but also tend to play nice and plug into other existing products well, and focus on doing one thing well - as opposed to enterprise products that try to do almost a little of everything. Developers and testers can “plug-n-play” to try out different tools and this seems to align with DevOps’ Third Way of continual experimentation and learning where testers get their hands dirty with the tool and learn if it fits their objectives well - looking for small wins that are measurable. If that does not suit their use cases, the transparent nature of the source code makes it modifiable for each tester’s own needs. At the same time, open source projects also rely on developers to give feedback and contribute to the projects in an organic manner, which is essential for the continuous improvement and growth of projects in a two-way relationship. With the vast variety of knowledge and tools in the open source space, developers and testers are spoilt for choices. Open source projects will only continue to grow in numbers as developers and testers build upon existing projects to achieve greater goals.
Top comments (0)