Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Unit testing is a crucial aspect of software development and helps to ensure that individual units of code are working as intended. In Java, the most popular framework for unit testing is JUnit. In this article, we will go over the basics of how to write and run unit tests in Java using the popular testing framework, as well as some best practices for unit testing.

TL;DR: There is a common belief that when it comes to uncovering bugs in the DevSecOps cycle, catching things early on is often better. While this approach certainly works well for Software Composition Analysis (SCA) and Static Application Security Testing (SAST), it doesn’t really apply to Dynamic Application Security Testing (DAST) in modern environments.

Most developers, including myself, have written unit tests before. Fuzz testing on the other hand has only started seeing widespread industry usage in recent years. Yet, some voices are already praising fuzz testing as the more effective approach, due to its ability to automatically generate negative and invalid test inputs. Let's put this claim to the test and see how these two approaches match up.

Creating effective test cases and the right testing strategy for Java applications can be a time-consuming and complex task. This is where specialized testing solutions come in. With the right setup, developers can catch bugs early in the development process, before they become more difficult and expensive to fix. Additionally, testing methods can help identify and mitigate security vulnerabilities, which is critical for protecting sensitive data and maintaining the integrity of the application.

Many companies provide legacy static application security testing (SAST) tools or engines, but their usefulness has not kept pace with the needs of an application-driven world. In order to succeed, businesses need a modern approach to SAST that will greatly improve it’s value in the software development lifecycle. In this blog, I look at the problems with traditional SAST tools, why there needs to be a change of approach in the SAST market, and what the future holds for SAST.

We live in a world that depends on embedded software. It’s in the cars we drive, the elevators we take and the airplanes we travel in. As these systems become more and more complex, it becomes increasingly challenging to ensure that the interaction between embedded software and hardware remains functional and secure. Due to the nature of embedded systems and the devastating consequences of failures, many traditional testing methods fall short of providing adequate security for them.