Category Archives: Security

Infection Method – Sub-Domain Takeover

Posted on by Leave a comment

A subdomain takeover is a type of cybersecurity vulnerability that occurs when an attacker gains control of a subdomain of a website or a domain name. This attack can seriously affect the security and functionality of a web application or website. In this explanation, we’ll look at subdomain takeovers, how they work, the risks they pose, and how to prevent them.

Introduction to subdomains

To understand what a subdomain takeover is, we need to understand the concept of subdomains. In the context of the Internet, a domain name such as “example.com” serves as the primary address for a website. However, a domain name can be further divided into subdomains, which act as separate sections or branches of the main domain. Subdomains are often used for organisational purposes, categorising different website areas, or providing specific services.

For example, consider the subdomains of the abc.com domain:

  • http://www.abc.com (for the main website)
  • blog.abc.com (for a blog section)
  • shop.abc.com (for an online shop)
  • mail.abc.com (for email services)
  • api.abc.com (for application programming interfaces)

These subdomains can be independently configured to provide different content or applications. Although subdomains are part of the same parent domain, they may be hosted on other servers or managed by different teams within the same organisation.

What is a subdomain takeover?

A subdomain takeover occurs when an unauthorised person or organisation gains control of a subdomain of a domain and thereby effectively takes ownership of it. This unauthorised control can lead to various security risks and potential misuse. The key factors contributing to subdomain takeover are misconfigurations, abandoned resources, and external service integrations.

Here are the main reasons why subdomain takeovers can occur:

Misconfigurations:

Web administrators and developers can accidentally misconfigure DNS records or forget to remove DNS records for no more prolonged use subdomains. These misconfigurations can allow an attacker to take control of a subdomain.

Abandoned resources:

Organisations can create subdomains for specific projects, campaigns, or temporary services and then abandon them later. If an attacker discovers an abandoned subdomain, they can claim it as their own and potentially use it for malicious purposes.

External service integrations:

Many websites integrate third-party services, such as content delivery networks (CDNs), cloud services or hosted applications. These services often require the creation of subdomains that point to the third-party service provider’s infrastructure. If the external service becomes vulnerable, attackers can exploit it to take over the associated subdomain.

How subdomain takeovers work

Subdomain takeovers result from vulnerabilities due to misconfigured DNS records, abandoned resources, or compromised external services.

Incorrectly configured DNS entries:

CNAME Records: A common misconfiguration involves CNAME (canonical name) records. A CNAME record maps a subdomain to another domain or subdomain. If a subdomain is incorrectly pointed to a domain controlled by an attacker, the attacker can effectively take over the subdomain.

Wildcard entries:

Wildcard DNS records are used to direct all subdomains of a domain to a common destination. If a subdomain with a wildcard entry is no longer claimed or points to an attacker’s server, the attacker can control all subdomains.

Abandoned resources:

Subdomains created for temporary projects, campaigns, or services may be forgotten or abandoned after their purpose has been served. Attackers can search for and claim such subdomains if they are available for registration or reconfiguration. I want to describe an example I have found several times in projects.

Let’s assume a service is hosted externally. For example, a virtual machine is created and assigned a logical name in Heroku. This typically looks like this: You can choose a name to which the external operator’s domain is added. In this example, it is demapp.heroku.com. This service is no longer needed and will be cancelled by the customer. However, there are still entries in the DNS configuration that point to demoapp.heroku.com. This can be, for example, a redirect from your own subdomain in this example, demoapp.abc.com. The attacker now creates an instance on Heroku and gives it the name demoapp, leading to the complete name demoapp.heroku.com. Now, the attacker only has to listen to the ports and analyse which requests arrive at this machine and can build his attack vector based on this. For example, he can set up a corresponding compromised service that responds to these requests.

Compromised external services:

Some subdomains are created to link to external services or resources provided by third parties. Attackers can tamper with the associated subdomains if these external services are compromised or misconfigured.

In these scenarios, the attacker effectively takes control of the subdomain by configuring the DNS records or exploiting vulnerabilities. Once they control the subdomain, they can host malicious content, launch phishing attacks, or commit other forms of cybercrime.

In these scenarios, the attacker effectively takes control of the subdomain by configuring the DNS records or exploiting vulnerabilities. Once they control the subdomain, they can host malicious content, launch phishing attacks, or commit other forms of cybercrime.

Risks and consequences of subdomain takeovers

Subdomain takeovers pose significant risks to websites’ and web applications’ security, reputation and functionality. The consequences of a successful subdomain takeover can be severe and far-reaching, including:

Data theft:

Attackers can use subdomains to steal sensitive data such as user credentials, personal information, or financial data.

Phishing attacks:

Subdomain takeovers are often used in phishing campaigns. Attackers can create convincing fake login pages or legitimate content to trick users into revealing their credentials.

Malware distribution:

Malicious files or software can be hosted on the compromised subdomain, which can then be used to distribute malware to unsuspecting visitors.

Denylisting: 

Search engines and email providers can denylist the parent domain if they detect malicious activity on a subdomain. This may impact website visibility and email communications.

Brand damage:

A subdomain takeover can damage an organisation or website’s reputation and lose trust among users and customers.

Financial loss:

Depending on the severity of the attack, a company could face financial losses, lawsuits, and fines.

Loss of control:

Once an attacker has control of a subdomain, it becomes difficult for the rightful owner to regain control and limit the damage.

Legal consequences:

Unauthorised access to or control over subdomains can result in legal consequences and penalties for the attacker.

Practical examples

To illustrate the real-world impact of subdomain takeovers, let’s look at a few notable cases:

Uber:

In 2015, researchers discovered a subdomain takeover vulnerability in Uber’s system. The ride-hailing company had a subdomain called riders.uber.com that was vulnerable to a takeover. Attackers may have used this subdomain to launch phishing attacks against Uber users. Uber immediately addressed the issue after being informed by researchers.

GitHub pages:

GitHub Pages is a popular platform for hosting websites and documentation. In 2017, a researcher found that GitHub Page’s subdomains were vulnerable to a takeover when users deleted their repositories but left the associated DNS records intact. Attackers could then claim the subdomains and host malicious content. GitHub has since taken measures to prevent such takeovers.

Shopify:

Shopify, a central e-commerce platform, faced a subdomain adoption issue in 2019. An attacker discovered that he could claim abandoned Shopify store subdomains and potentially use them for fraud. Shopify has fixed the vulnerability and improved its security measures.

These cases show that subdomain takeovers can affect both small and large organisations. Timely identification and remediation of such vulnerabilities is critical to maintaining the security and trustworthiness of online services.

Prevent subdomain takeovers

Preventing subdomain takeovers requires a combination of proactive measures and best practices. Here are steps companies can take to mitigate the risk of subdomain takeovers:

Regular DNS Audits:

Perform routine DNS record checks to identify misconfigurations or abandoned subdomains. Remove unnecessary DNS records and update records for active subdomains.

Best practices for CNAME records:

When using CNAME records, be careful where they point. Make sure you trust the target and check CNAME configurations regularly.

Wildcard DNS records:

Use wildcard DNS records carefully. Avoid directing all subdomains to a single destination, as this can create a single point of failure.

Subdomain Registration Guidelines:

Implement clear guidelines for subdomain creation and management. Ensure that subdomains are registered with valid entities within the organisation and follow a consistent naming convention.

Automated scanning:

Use automated scanning tools to identify subdomains at risk of takeover. These tools can help identify misconfigurations and vulnerabilities.

Security of external services:

If you use external services requiring subdomains, ensure those services are secure. Regularly monitor and audit the security of these services to prevent potential vulnerabilities.

DNS rate limit:

Implement rate limiting for DNS requests to protect against reconnaissance attacks from potential attackers.

Access control:

Restrict access to DNS configuration and ensure only authorised personnel can change DNS records.

Vulnerability disclosure programs:

Encourage security researchers and users to report subdomain takeover vulnerabilities responsibly. Establish a process for receiving and processing such reports.

Monitor subdomain activity:

Monitor subdomain activity and set up alerts for suspicious or unauthorised changes to DNS records.

Conclusion

Subdomain takeovers represent a widespread cybersecurity threat and can significantly impact website owners and users. These takeovers are often due to misconfigured DNS records, abandoned resources, or compromised external services.

To protect against subdomain takeovers, companies/teams must proactively monitor and secure their subdomains. This includes regular DNS audits, best practices for managing DNS records, and a strong awareness of potential vulnerabilities in external services.

Happy Coding

Sven

Infection Method – Domain Takeover

Posted on by Leave a comment

In this post, we will look at another method of infection. These are the attack vectors via domain names. This can happen at the main level, i.e. the domain itself, or via sub-domains. But what exactly is a domain takeover attack?

A domain takeover is a cyberattack when an attacker gains control of a domain name owned by another person or organization. This can have severe consequences as the attacker can use the domain for malicious purposes, such as spreading malware, phishing, or taking control of a company’s online presence.

Below, we will look at different ways in which such a takeover can take place:

1. Expired domain:

A common possibility of domain takeover is that the owner of a domain forgets to renew it. When a domain registration expires, it may be available for purchase by anyone. Attackers can monitor the expiration of valuable domains and quickly register them as soon as they become available. If you have set up automatic renewal with your domain registrar, this should not happen. But sometimes companies (or people) get rid of old domains. This could be because the acquired company is now fully integrated and the domain is no longer needed, or because a project has expired, or or or. The problem, then, is that these domains may still be included in the internal configurations and firewall rules. The attacker then exploits the extended privileges typically intended for their own systems. If the old domains are now for sale, the attacker has purchased them regularly, and the own configurations still need to be updated, an attack can be carried out.

2. Domain-Hijacking: 

In some cases, attackers can use social engineering techniques to trick domain registrars or Domain Name System (DNS) providers into giving them domain control. This could mean impersonating the domain owner or providing false information to the domain registrar. Here, however, you have to think in different directions. Here is an example of the domain used for a reverse attack on a Maven repository. An open-source project named ABC does not have its associated domain secured. The Maven artefacts are stored in the central Maven Central, for example, under “org.abc”. The attacker now registered the domain abc.org and then contacted the operator of Maven Central, saying that he needed access to his Maven repository. He has lost his access to data. The operator of Maven-Central then asks the applicant to store a TXT entry with a specific code (in this case, it is the ticket number of the request) in the DNS configuration. Once this code is available via DNS, rights to the repository are granted. The attacker can now deposit his Maven artefacts in the repository and thus make them generally available.  

3. DNS-Misconfiguration: 

Sometimes, domain takeovers occur due to misconfigurations in DNS settings. Attackers can exploit these misconfigurations to gain control of the domain or subdomains and thereby redirect traffic to malicious servers.

3.1 What is a critical DNS misconfiguration?

A critical Domain Name System (DNS) misconfiguration is an error or error in the configuration of a DNS system that can have severe consequences for the availability, security, and functionality of a domain or network. DNS is a crucial Internet component that translates human-readable domain names (like example.com) into IP addresses that computers use to identify and communicate with each other. When DNS misconfiguration occurs, it can lead to various problems, including:

1. Service interruption: 

A misconfigured DNS record can cause service outages, making a website or other online services inaccessible.

2. Vulnerabilities: 

Misconfigurations can lead to security vulnerabilities, e.g. B., to reveal sensitive information, enable unauthorized access, or enable DNS-related attacks such as DNS cache poisoning or DNS spoofing.

3. Data Loss: 

Incorrect DNS configurations can lead to data loss as changes to DNS records can result in email misdirection or loss of crucial domain-related information.

4. Performance Issues: 

Suboptimal DNS configurations can slow down domain name resolution and cause delays in website loading or other network activity.

5. Traffic Diversion: 

DNS misconfigurations can inadvertently direct traffic to the wrong IP addresses or locations, potentially leading to data leaks, man-in-the-middle attacks, or other unintended consequences.

6. Domain-Hijacking: 

This is exactly the case of domain takeover considered here, in which unauthorized persons gain control of a domain and the services associated with it. Common examples of critical DNS misconfigurations include errors in DNS records (e.g. A, CNAME, MX, TXT records), incorrect IP address assignments, outdated or expired DNS information, and unauthorized changes to DNS settings .

4. Phishing/Theft Of Credentials: 

Attackers can also use phishing attacks to trick domain owners or those with administrative access to domain management accounts into revealing their credentials. Once they have the credentials, they can log in and take control of the domain.

5. Subdomain-TakeOver: 

A subdomain takeover occurs when an unauthorized person or organization gains control of a subdomain of a domain and thereby effectively takes ownership of it. This unauthorized control can lead to various security risks and potential misuse. The key factors contributing to subdomain takeover are misconfigurations, abandoned resources, and external service integrations.

6. DNS-Cache-Poisoning: 

In some cases, attackers may attempt to poison DNS caches, causing them to resolve a legitimate domain into a malicious IP address. This can lead to a temporary domain takeover as users are redirected to the attacker’s server rather than the intended website.

Once the attacker gains control of a domain, they can use it for various malicious purposes, such as hosting fake websites for phishing attacks, distributing malware, or intercepting communications. This can damage the domain owner’s reputation, jeopardize user security and privacy, and result in legal and financial consequences for the legitimate domain owner.

An example from history:

A notable historical example of a domain takeover is the case of the Syrian Electronic Army (SEA) in 2013. The SEA was a group of hacktivists who supported the Syrian government and targeted various websites, social media accounts and domains to promote their political agenda. One of the most high-profile incidents involved the takeover of the Twitter accounts and the domain of several well-known media organizations.

In April 2013, SEA compromised the domain registration account of MarkMonitor, a domain registrar and provider of brand protection services. Using stolen credentials or other means, SEA accessed the New York Times’ domain registration records. They changed the domain’s DNS records, redirecting traffic from the New York Times website to a server controlled by the SEA. As a result, visitors to The New York Times website were greeted with a message from SEA instead of the expected news content.

This domain takeover disrupted the New York Times’ online operations and raised concerns about the security of domain registrars. The incident highlighted the importance of protecting domain management accounts and the potential impact of domain takeovers on well-known media organizations and their readership.

How do you protect yourself from these attacks?

To protect yourself from domain takeovers, it is essential for domain owners to:

1. Keep your domain registrations current and renew them on time.

2. Use strong authentication and authorization mechanisms for domain management accounts.

3. Regularly monitor and check your DNS configurations for misconfigurations.

4. Educate your team about the risks of social engineering and phishing attacks.

5. Use domain security services and technologies to detect and prevent unauthorized changes to domain settings.

This is not an exhaustive list, but it is a good start to preventing the most common attack vectors.

Conclusion:

We have seen many different attack vectors that can lead to a loss of control of the (sub)domain. These attacks are still prevalent and are successfully used even on large companies. Unfortunately, many small companies have exactly these vulnerabilities of abandoned resources in the sub-domain area. I recommend that every project member pay close attention to what else can be actively found in the configurations of the firewalls and DNS, even when it comes to testing and development infrastructure.

Happy Coding

Sven

EclipseStore High-Performance-Serializer

Posted on by Leave a comment

I will introduce you to the serializer from the EclipseStore project and show you how to use it to take advantage of a new type of serialization.

Since I learned Java over 20 years ago, I wanted to have a simple solution to serialize Java-Object-Graphs, but without the serialization security and performance issues Java brought us. It should be doable like the following…

byte[] data = serializer.serialize(objectGraph);
Node objectGraphDeserialized = serializer.deserialize(data);

If you want to know how this is doable with the new Open-Source Project EclipseSerializer? You are right here.

Before we look at the Open-Source project EclipseStore Serializer, I want to recap a bit of the challenges coming from the Java Serialization itself. This will be the background information to see how powerful the project is. 

Java Serialization in a nutshell

Java Serialization is a mechanism provided by the Java programming language that allows you to convert the state of an object into a byte stream. This byte stream can be easily stored in a file, sent over a network, or otherwise persisted. Later, you can deserialize the byte stream to reconstruct the original object, effectively saving and restoring the object’s state.

Here are some key points about Java Serialization:

Serializable Interface: To make a Java class serializable, it needs to implement the `Serializable` interface. This interface doesn’t have any methods; it acts as a marker interface to indicate that the objects of this class can be serialized.

   import java.io.Serializable;
   public class MyClass implements Serializable {
       // class members and methods
   }

Serialization Process: To serialize an object, you typically use `ObjectOutputStream`. You create an instance of this class and write your object to it. For example:

 try (FileOutputStream fileOut = new FileOutputStream("object.ser");
       ObjectOutputStream out = new ObjectOutputStream(fileOut)) {
       MyClass obj = new MyClass();
       out.writeObject(obj);
   } catch (IOException e) {
       e.printStackTrace();
   }

Deserialization Process: To deserialize an object, you use `ObjectInputStream`. You read the byte stream from a file or network and then use `ObjectInputStream` to recreate the object.

try (FileInputStream fileIn = new FileInputStream("object.ser");
       ObjectInputStream in = new ObjectInputStream(fileIn)) {
       MyClass obj = (MyClass) in.readObject();
       // Now 'obj' contains the deserialized object
   } catch (IOException | ClassNotFoundException e) {
       e.printStackTrace();
   }

Versioning Considerations: If you change a serialised class’s structure (e.g., adding or removing fields or changing their types), the deserialization of old serialized objects may fail. Java provides mechanisms like serialVersionUID to help with versioning and compatibility.

Security Considerations: Serialization can be a security risk, especially if you deserialize data from untrusted sources. Malicious code can be executed during deserialization. To mitigate this risk, you should carefully validate and sanitize any data you deserialize or consider alternative serialization mechanisms like JSON or XML.

Custom Serialization: In your class, you can customize the serialization and deserialization process by providing `writeObject` and `readObject` methods. These methods allow you to control how the object’s state is written to and read from the byte stream.

In summary, Java Serialization is a valuable feature for persisting objects and sending them across a network. However, it comes with some challenges related to versioning and security, so it should be used cautiously, especially when dealing with untrusted data sources.

What are the security issues

Java Serialization can introduce several security issues, particularly when deserializing data from untrusted sources. Here are some of the security concerns associated with Java Serialization:

Remote Code Execution: One of the most significant security risks with Java Serialization is the potential for remote code execution. When you deserialize an object, the Java runtime system can execute arbitrary code contained within the serialized data. Attackers can exploit this to execute malicious code on the target system. This vulnerability can lead to serious security breaches.

Denial of Service (DoS): An attacker can create a serialized object with a large size, causing excessive memory consumption and potentially leading to a denial of service attack. Deserializing large objects can consume significant CPU and memory resources, slowing down or crashing the application.

Data Tampering: Serialized data can be tampered with during transmission or storage. Attackers can modify the serialized byte stream to alter the state of the deserialized object or introduce vulnerabilities.

Insecure Deserialization: Deserializing untrusted data without proper validation can lead to security issues. For example, if a class that performs sensitive operations is deserialized from untrusted input, an attacker can manipulate the object’s state to perform unauthorized actions.

Information Disclosure: When objects are serialized, sensitive information may be included in the serialized form. If this data is not adequately protected or encrypted, an attacker may gain access to sensitive information.

How To Mitigate Serialization Issues

To mitigate these security issues, consider the following best practices:

Avoid Deserializing Untrusted Data: If possible, avoid deserializing data from untrusted sources altogether. Instead, use safer data interchange formats like JSON or XML for untrusted data. (Or use the EclipseSerializer 😉 )

Implement Input Validation: When deserializing data, validate and sanitize the input to ensure it adheres to expected data structures and doesn’t contain unexpected or malicious data.

Use Security Managers: Java’s Security Manager can be used to restrict the permissions and actions of deserialized code. However, it’s important to note that Security Managers have been deprecated in newer versions of Java.

Whitelist Classes: Limit the classes that can be deserialized to a predefined set of trusted classes. This can help prevent the deserialization of arbitrary and potentially malicious classes.

Versioning and Compatibility: Be cautious when making changes to serialized classes. Use `serialVersionUID` to manage versioning and compatibility between different versions of serialized objects.

Security Libraries: Consider using third-party libraries like Apache Commons Collections or OWASP Java Serialization Security (Java-Serial-Killer) to help mitigate known vulnerabilities and prevent common attacks.

In summary, Java Serialization can introduce serious security risks, especially when dealing with untrusted data. It’s essential to take precautions, validate inputs, and consider alternative serialization methods or libraries to enhance security. Additionally, keeping your Java runtime environment up to date is crucial, as newer versions of Java may include security improvements and fixes for known vulnerabilities.

Why is JSON or XML not the perfect solution for the JVM?

Many papers and lectures recommend circumventing the security risks of serialization by using XML or JSON. This is a structured representation of the data that is to be transferred. There are also security problems, but I will address these in a separate article. However, what should be addressed are two things. First, the data must be converted into a text representation. This usually requires more data volume than with a pure binary model. In addition, data such as the binary data of images must be recoded so that only printable or UTF-8 characters can be transmitted. This process requires a lot of time and usually a lot of memory when transforming it into XML and back from XML into the original format.

The second point that causes problems in most cases is the data structure. In XML and JSON, object references can only be stored in a more manageable manner. This makes processing many times more complicated, slower and more resource-intensive. Even though many solid solutions can be used to convert Java objects into XML or JSON, I recommend looking for new approaches occasionally.

EclipseStore – Serializer – Practical Part

Now, let’s get to the practical stuff in this article. The dependency is needed first. To do this, we add the following instructions to the pom.xml. The first release was prepared when writing this article, and a SNAPSHOT version (1.0.0-SNAPSHOT) was available from the repositories. In this case, you still have to use the SNAPSHOT repositories (https://oss.sonatype.org/content/repositories/snapshots)

Definition inside the pom.xml.

<dependency>
   <groupId>org.eclipse.serializer</groupId>
   <artifactId>serializer</artifactId>
   <version>{maven-version-number}</version>
</dependency>

The rest will happen quickly once we’re ready and have fetched the dependency. For the first test, we created a class called Node. Each Node can have a right and a left child. With this, we can create a tree.

private String id;
private Node leftNode;
private Node rightNode;

As an example, I created the following construct and then serialized and de-serialized it once using the serializer.

Node rootNode = new Node("rootNode");
Node leftChildLev01 = new Node("Root-L");
Node rightChildLev01 = new Node("Root-R");
leftChildLev01.addLeft(new Node("Root-L-R"));
leftChildLev01.addLeft(new Node("Root-L-L"));
rightChildLev01.addLeft(new Node("Root-R-L"));
rightChildLev01.addRight(new Node("Root-R-R"));
rootNode.addLeft(leftChildLev01);
rootNode.addRight(rightChildLev01);
Serializer<byte[]> serializer = Serializer.Bytes();
byte[] data = serializer.serialize(rootNode);
Node rootNodeDeserialized = serializer.deserialize(data);
System.out.println(rootNode.toString());
System.out.println(" ========== ");
System.out.println(rootNodeDeserialized.toString());

Now, let’s see whether this also works with a Java object graph. To do this, the class representing the node is changed so that a father node can also be defined. Cycles can now be set up.

public class GraphNode {
   private String id;
   private GraphNode parent;
   private List<GraphNode> childGraphNodes = new ArrayList<>();

We take the graph listed here as an example.

GraphNode rootNode = new GraphNode("rootNode");
GraphNode child01Lev01 = new GraphNode("child01Lev01");
GraphNode child02Lev01 = new GraphNode("child02Lev01");
rootNode.addChildGraphNode(child01Lev01);
rootNode.addChildGraphNode(child02Lev01);
child01Lev01.setParent(rootNode);
child02Lev01.setParent(rootNode);
GraphNode child01Lev02 = new GraphNode("child01Lev02");
GraphNode child02Lev02 = new GraphNode("child02Lev02");
child01Lev01.addChildGraphNode(child01Lev02);
child01Lev01.addChildGraphNode(child02Lev02);
child01Lev02.setParent(child01Lev01);
child01Lev02.setParent(child01Lev01);
GraphNode child01Lev03 = new GraphNode("child01Lev03");
GraphNode child02Lev03 = new GraphNode("child02Lev03");
child01Lev03.setParent(child02Lev01);
child02Lev03.setParent(child02Lev01);
child02Lev01.addChildGraphNode(child01Lev03);
child02Lev01.addChildGraphNode(child02Lev03);
//creating cycles
rootNode.addChildGraphNode(child01Lev03);
rootNode.setParent(child02Lev03);

This graph is also processed without any problems, without the cycles causing any issues.

Serializer<byte[]> serializer = Serializer.Bytes();
byte[] data = serializer.serialize(rootNode);
GraphNode rootNodeDeserialized = serializer.deserialize(data);

You can make the examples even more complex and try out the subtleties of inheritance. New data types from JDK17 are also supported. This means I have a potent tool to handle various tasks. For example, one use can be found in another Eclipse project called EclipseStore. A persistence mechanism is provided here based on this serialization. But your own small projects can also benefit from this. I will show how quickly this can be integrated into a residual service.

Building A Simple REST Service

If you want to create a simple REST service for transferring byte streams in Java without using Spring Boot, you can use the Java SE API and the HttpServer class from the com.sun.net.httpserver package, which allows you to create an HTTP server. 

  • We create an HTTP server on port 8080 and define a context for handling requests to “/api/bytestream.”
  • The ByteStreamHandler class handles both POST requests for uploading byte streams and GET requests for downloading byte streams.
  • For POST requests, it reads the incoming byte stream, processes it as needed, and sends a response.
  • For GET requests, it sends a predefined byte stream as a response.

Remember that this is a simple example, and you can expand upon it to handle more complex use cases and error handling as needed for your specific application. Also, note that the com.sun.net.httpserver package is part of the JDK, but it may not be available in all Java distributions.

public class ByteStreamHandler implements HttpHandler {
   @Override
   public void handle(HttpExchange exchange) throws IOException {
       String requestMethod = exchange.getRequestMethod();
       if (requestMethod.equalsIgnoreCase("POST")) {
           // Handle POST requests for uploading byte streams
           handleUpload(exchange);
       } else if (requestMethod.equalsIgnoreCase("GET")) {
           // Handle GET requests for downloading byte streams
           handleDownload(exchange);
       }
   }

   private void handleUpload(HttpExchange exchange) throws IOException {
       // Get the input stream from the request
       InputStream inputStream = exchange.getRequestBody();
       // Read the byte stream and process it as needed
       ByteArrayOutputStream byteArrayOutputStream 
         = new ByteArrayOutputStream();
       byte[] buffer = new byte[1024];
       int bytesRead;
       while ((bytesRead = inputStream.read(buffer)) != -1) {
           byteArrayOutputStream.write(buffer, 0, bytesRead);
       }
       // Process the uploaded byte stream 
       // (e.g., save to a file or perform other actions)
       byte[] data = byteArrayOutputStream.toByteArray();
       // Do something with 'data'
       Serializer<byte[]> serializer = Serializer.Bytes();
       GraphNode deserialized = serializer.deserialize(data);
       //process the data
       System.out.println("deserialized = " + deserialized);
       // Send a response (you can customize this)
       String response = "Byte stream uploaded successfully.";
       exchange.sendResponseHeaders(200, response.length());
       OutputStream os = exchange.getResponseBody();
       os.write(response.getBytes());
       os.close();
   }
   private void handleDownload(HttpExchange exchange) throws IOException {
       // Simulate generating and sending a byte stream as a response
       String response = "Hello, Byte Stream!";
       Serializer<byte[]> serializer = Serializer.Bytes();
       byte[] data = serializer.serialize(response.getBytes());
       exchange.sendResponseHeaders(200, data.length);
       OutputStream os = exchange.getResponseBody();
       os.write(data);
       os.close();
   }
}

Conclusion:

We’ve looked at the typical problems with Java’s original serialization and how cumbersome the implementation is to use. The detour via JSON and XML is unnecessary when communicating from JVM to JVM using the open-source Eclipse Serializer project. There are no restrictions when it comes to modelling a graph, as not only are the current new data types up to and including JDK17 already processed, but cycles within the graph are also no problem.

Using the Serializable interface is also unnecessary and does not influence processing. The easy handling allows it to be used even in tiny projects such as the REST service shown here using on-board JDK resources. A larger project that uses the serializer is the open-source project EclipseStore. A high-performance persistence mechanism for the JVM is offered here.

Happy Coding

Sven

TDD and the impact on security

Posted on by Leave a comment

Test-driven development (TDD) is a software development approach that prioritizes writing automated tests while creating the actual code. There follows a cycle of writing a failed test, writing the code to make the test pass, and then refactoring the code. TDD was originally developed to ensure the quality, maintainability and expandability of the software created over the long term. The specific knowledge about the individual source text passages should also be shown in the tests. Thus, a transfer of responsibility between developers is supported. Better than any documentation, tests are always up-to-date regarding the function that has been implemented in the source code.

However, TDD also has a positive impact on the security of a program. And that’s what we’re going to look at now.

But first, let’s get back to TDD. There are a variety of theoretical approaches here. I will briefly touch on them here to give an overview. The question to be addressed is whether the TDD approach influences the effect.

Classic TDD – Kent Beck

Unit tests and units tested with them are continuously developed in parallel. The actual programming is done in small, repeating micro-iterations. One such iteration, which should only take a few minutes, consists of three main parts, known as the red-green refactoring.

Red: Write a test to test a new behaviour (functionality) to be programmed. You start with the simplest example. If the feature is older, it could also be a known bug or new functionality to be implemented. This test is initially not fulfilled by the existing program code, so it must fail.

Green: Change the program code with as little effort as possible and add to it until it passes all tests after the test run then initiated.

Then clean up the code (refactoring): remove repetitions (code duplication), abstract if necessary, align with the binding code conventions, etc. In this phase, no new behaviour may be introduced that would not already be covered by tests. After each change, the tests are performed; if they fail, it is impossible to replicate what appears to be a bug in the code being used. Cleanup aims to make the code simple and easy to understand.

These three steps are repeated until the known bugs are fixed, the code provides the desired functionality, and the developer can’t think of any more useful tests that could fail. The program-technical unit (unit) treated in this way is considered complete for now. However, the tests created together with her are retained to be able to test again after future changes as to whether the behavioural aspects that have already been achieved are still fulfilled.

For the changes in step 2 – also called transformations – to lead to the goal, each change must lead to a more general solution; for example, she may not only edit the current test case at the expense of others. Tests that get more and more detailed bring the code to a more and more general solution. Regular attention to transformation priorities leads to more efficient algorithms.

Consistently following this approach is an evolutionary design method, where every change evolves the system.

Outside in TDD

Outside-In Test-Driven Development (TDD) is an approach to software development that places emphasis on starting the development process first by creating high-level acceptance tests or end-to-end tests that demonstrate the desired behaviour of the system from his point of view to define users or external interfaces. It is also commonly referred to as behaviour-directed development (BDD).

With Outside-In TDD, the development process begins with writing a failed acceptance test that describes the desired behaviour of the system. This test is usually written from a user’s perspective or a high-level component that interacts with the system. The test is expected to initially fail as the system does not have the required functionality.

Once the first acceptance test has been performed, the next step is to write a failing unit test for the smallest possible unit of code that will pass the acceptance test. This unit test defines the desired behaviour of a specific module or component within the system. The unit test fails because the corresponding code still needs to be implemented.

The next step is implementing the code to make the failed unit test succeed. The code is written incrementally, focusing on the immediate needs of the failed test. The developer writes further tests and code step by step until the acceptance test is passed and the desired behaviour of the system is achieved.

The idea behind Outside-In TDD is to drive the development process from the outside, starting with the higher-level behaviour and moving inward to the lower-level implementation details. This approach helps ensure that the system is developed to meet the needs and expectations of its users. It also encourages component testability and decoupling by encouraging the creation of small, focused tests and modular code.

By practising outside-in TDD, developers can gain confidence in their code and ensure the system behaves as expected. It also helps uncover design flaws early in the development process and encourages the creation of loosely coupled and easily maintainable code.

Overall, Outside-In TDD is a methodology that combines testing and development, focusing on providing value to users and driving the development process from an outside perspective.

Acceptance Driven TDD

In test-driven development, system tests are continuously developed or at least specified before the system. In test-driven development, system development is no longer to meet written requirements but to pass specified system tests.

Acceptance Test-Driven Development (ATDD), while related to Test-Driven Development, differs in approach from Test-Driven Development. Acceptance test-driven development is a communication tool between the customer or user, the developer and the tester to ensure the requirements are well described. Acceptance test-driven development does not require automation of test cases, although it would be useful for regression testing. The acceptance tests for test-driven development must also be legible for non-developers. In many cases, the tests of test-driven development can be derived from the tests of acceptance test-driven development. For this approach to be used for system security, the boundary conditions must go beyond the normal technical aspects, which are only considered in some cases.

What test coverage should I use?

It is important for the effect on security that tests run automatically. These then lead to test coverage that can be measured and compared to previous runs. The question arises as to which test coverage will be most suitable. It has been shown that there are significant differences in the strength of the respective approaches. I am a strong proponent of mutation test coverage, as it is one of the most effective test coverages. If you want to know more here, I refer to my video on “Mutation Testing in German” or “Mutation Testing in English” on my YouTube channel. In any case, it is important that the better the test coverage, the greater the effect that can be achieved.

How exactly is the security of the application supported?

1. Identify vulnerabilities early: Writing tests before implementing features help identify potential security gaps early. By considering security concerns during the test design phase, developers can anticipate possible attack vectors and design their code with security guidelines in mind. This proactive approach makes it possible to detect security problems before they become deeply embedded in the code base.

2. Encouraging Safe Coding Practices: TDD encourages writing modular, well-structured, and testable code. This enables developers to adopt secure coding practices such as input validation, proper error handling, and secure data storage. By writing tests that simulate different security scenarios, developers are more likely to consider edge cases and verify that their code behaves securely.

3. Regression Testing for Security: TDD relies on running automated tests regularly to maintain existing functionality as new code is added. This approach helps prevent a decline in security-related issues. If a security-related test case exists and initially passes, subsequent changes to it can be tested to ensure that vulnerabilities were not accidentally introduced.

4. Building a Security-Aware Culture: TDD’s incorporation of security testing as an integral part of the development process helps foster a security-aware culture within the development team. By performing security-focused testing alongside functional testing, developers are more likely to prioritize security and see it as a fundamental aspect of their job. This mindset encourages a proactive attitude towards security rather than just seeing it as a side issue.

5. Facilitate Collaboration and Code Review: TDD encourages collaboration and code review between team members. When developers first write tests, they can discuss security concerns and get feedback from peers. This collaborative approach increases overall security awareness within the team and enables early detection and resolution of security issues.

Although TDD is not a security panacea, it offers a systematic and disciplined development approach that indirectly strengthens software security posture. By promoting security-centric thinking, promoting secure coding practices, and facilitating early detection of vulnerabilities, TDD can help build more secure and resilient applications. However, it is important to note that additional security measures such as threat modelling, code analysis, and penetration testing should also be included to meet security requirements fully.

A few more practical approaches

What are Compliance Issues, and how to remove them?

The compliance issues are elements that run under a license and may not be used in this way in the project. This can happen in all technology areas within a project. Libraries or frameworks used do not usually change their license over the years, but it occasionally happens. All dependencies of the elements used must also be checked. And that’s up to the last link.

One must replace the affected element with a semantic equivalent available under an appropriate license to fix such a violation.

What are Vulnerabilities, and how to remove them?

Vulnerabilities are unintentional errors in the source code that allow the system to be manipulated to its advantage. These errors can occur throughout the tech stack. It is important to recognize all vulnerabilities in all technologies used to get an overview of which vulnerabilities can be exploited in which combination for an attack on this system. Individual considerations need to be clarified at this point. This holistic view enables the recognition of the different attack vectors and the identification of weak points that cannot be exploited in this system. This allows you to use your efforts in a targeted manner to secure the system.

Why do we need efficient dependency management?

What tools are available to developers to address compliance issues and vulnerabilities? The answer is obvious. This is where very effective dependency management combined with robust test coverage comes in handy. Because, in all cases, dependencies have to be exchanged. Even though it’s a surrogate for compliance issues, fixing vulnerabilities is the same dependency in a different version. This can be a higher or lower version. Overall, it is about the clever combination of the various elements. Strong test coverage facilitates the subsequent test to determine whether the functionality is still available.

Conclusion:

In summary, strong test coverage is beneficial when modifying and exchanging external elements as well as your own source code. Here you can rely on the results of the CI environment without having to add manual verifications and thus implement a fast and lean release process with as little time loss as possible.

Quality and safety support each other.

Happy coding

Sven

Introduction to the Linux Foundation’s SLSA project

Posted on by Leave a comment

Supply Chain Security is a hot topic these days. And more and more, we as developers are dealing with this daily. But what does this mean for us, and how is this influencing our job? I want to give an overview of common attacks against the Software Supply Chain from the developer’s view and will introduce the Open Source project SLSA from the Linux Foundation. 

a) Who is the project SLSA

Various experts from the security field started this project to share their knowledge, leading to the mentioned project. There is no company or governmental organisation behind this project. It is a pure Open Source project under the umbrella of the Linux Foundation. 

b) What is the goal of this project?

The SLSA project is open-source and will not provide its own source code. It is, therefore, not a classic open-source project to publish a specific solution. Instead, it is a documentation project to process knowledge about supply chain security in software development and make it freely accessible. The structure contains examples of where the events or attacks mentioned have been successfully taken and which countermeasures should be taken. We’ll look at the security levels provided a little later. The aim here is to allow the reader to prepare for these threats with specific steps slowly. 

After all, based on your options and the current environment, you have to decide which next steps and measures make sense to implement. 

c) What is the current status of the project?

The project is currently (beginning of 2022) still in the alpha phase. There is a lot of documentation, but some places still provide references to future content. So it’s always worth taking a look inside. Since this is an open-source project, you can, of course, also contribute yourself. Here you have the opportunity to make your expertise available to others. 

SLSA security levels?

a) Why do we need these security levels?

When you look around the SLSA project website for the first time, the description of the security levels quickly catches your eye. But what are these levels all about? With these levels, you want to achieve two things. First, it should help to enable a self-assessment. This first consideration serves to classify the own existing environment and to identify the primary weak points. The second goal of this level is to help you plan the following purposes that should be implemented to increase your protection significantly. These recommendations are based on evaluating many projects and environments and on the security experts’ knowledge. This enables you to use the available means and opportunities to increase your security. 

b) Level 0

The first level mentioned is marked with the number zero. This is the state in which no action has yet been taken. The documentation that describes the entire build process must be available and up-to-date to reach this level. This enables an initial analysis of the environment to be secured. It can also be seen as a way of taking stock.

c) Level 1

The level with the number one requires first actions on the environment. The point here is to list all the components used to create a binary file. Not only are the dependencies used listed, but all other metadata is recorded if possible. There is the term SBOM, Software Bills Of Materials in the industry. However, the term can be broadened considerably here. Within JFrog Artifactory, there is “build info”, which means a superset of SBOM. All sorts of metadata are recorded here, such as the operating system and version of the build machine, environment variables and their contents, etc. I have created my video for this.    

In this video, I’ll go over the details of SBOM and Build Info.

Within the SLSA project, the term SBOM or Build Info is not explicitly mentioned. Instead, the requirement is described more generally, and it is also clearly pointed out that this level does not yet help against the compromise itself. It is only the basis for the follow-up and the comprehensive risk assessment. Based on this level, one can start with vulnerability management.

d) Level 2

Level two describes code versioning software in combination with a hosted build service. With this combination, you want to trust the build service and thus trust the origin of the generated files. Here you must take a critical look at where and who will offer these services. The fundamental consideration is based on the assumption that a specialized provider has a better grip on the issue of security within the build infrastructure than you can guarantee yourself. However, the manipulation of protection of the build service can be increased in various ways.

e) Level 3

With level three, auditors are now included in the considerations. Here, trained security specialists are used to check the existing build environment for possible vulnerabilities. As part of an accreditation process, the auditors determine whether specific standards are met to ensure the verifiability of the source and the integrity of the provenance (origin). This level offers better protection than all previous levels to ward off well-known threats. Preventing cross-build contamination is an example.

f) Level 4

In the SLSA project, level four is the highest currently achieved. To reach this level, the following conditions are set. The first requirement describes the necessity that two people constantly carry out all changes. This does not only refer to the changes made to the source code. The term is broader here and also includes all changes to the system and the configurations. This ensures that no intentional or unintentional compromise can occur at any point. Such a process has prevented most bugs, vulnerabilities and compromise attempts.

The second requirement relates to the technical environment. It is assumed here that it is a hermetic and reproducible creation process. However, a distinction should be made between the requirement for hermetic builds and reproducible builds. The former guarantees that all required dependencies are known and checked for vulnerabilities. Here, of course, it plays a role from which sources these dependencies were obtained. On the other hand, reproducible builds help detect changes and conduct subsequent analyses. However, the reproducibility of a build is not a mandatory part of the fourth level.

g) Limitations

Even if many supply chain threads are addressed with the SLSA project, there are some limitations that I would like to list here.

1) The list of all dependencies in a project can simply become too large to be able to fully record and evaluate them. That can depend on different things. The point that shows this most clearly is based on the possibility of some dependency management systems not only specifying explicit dependency versions. In some scenarios, you can also define a version range. This now results in an exponential increase in all possible version combinations.

2) The number of all components to be backed up can exceed the available capacities. The teams then have to decide which elements are subjected to safety analysis.

3) The SLSA security levels are not transitive. This means that this component itself consists of components that have a lower security level. So here, you have to pay very close attention to the details.

4) Even if automation is the solution in many areas, there may be areas where this will not be possible. Again, this refers in many areas to closed-source projects. Here, some analyzes are simply not feasible. It must then be decided how this dependency will be classified on a case-by-case basis.

What are the requirements? 

All the requirements mentioned here are a little more detailed in reality. An overview of the requirements was provided to guide what exactly is meant by each point. Here, you can see which condition belongs to which level and how this is understood. Then the details are discussed, such as what difference it makes if you only use a building service or if you also use the “Build as Code” strategy. All the details are too extensive here, so I refer to the section on the project’s website.  

Supply Chain Threads

a) Overview 

To better understand the project and its limitations, you should look at the individual types of attacks on a typical software development environment. A distinction is generally made between source, image and dependency threads. The SLSA project also delimits precisely what it includes and what it does not.

The following overview comes directly from the project and will be further developed if necessary. At this point, one must not forget that this project is only in the alpha phase (early 2022). However, these types of attacks mentioned are timeless and apply to almost every development environment.

Let’s get to the source threads. This type of attack aims to compromise the source code itself. 

b.1) Bypass Code Review

The attack called “Bypass Code Review” describes a scenario in which an attempt is made to bypass the control mechanisms and directly add compromised source code to the project. Here public paths are taken to reach the destination. Such attacks were carried out on the Linux kernel, for example, via the mailing list. The best and probably simplest way to thwart such attacks is to have all source code changes checked independently by at least two people. However, at this point, one must also find ways to prevent mutual “covering up”.

b.2) Compromised Source Control System

If importing compromised source code does not work, you can try to attack the CVS itself. Attempts are being made here to make changes to the source code on the server, bypassing the official channels. A prominent example is a successful attack on the source code of PHP. The self-managed system was attacked, and the changes were imported directly as a commit. Only securing the system helps against this type of attack. To manage such a system yourself, you must have the necessary resources and knowledge. In this case, it is often easier and cheaper to use a managed system with Github.

Next, we come to the build threads.

b.3) Modified Source Code after Source Control

The source code cannot only be changed where it is stored. When a Build process is started, the source code is fetched from the specified source. The source text on the build page can also be modified before the translation process starts. One attack in which this approach was used is the “Webmin” project. Here, additional and modified source texts were injected into the translation process. The agents responsible for carrying out the individual build steps must be secured to prevent this attack. Here, too, one has to weigh up how much of this work is carried out by oneself since how safe such an environment depends primarily on one’s own abilities. 

b.4) Compromised Build Platform

Since the built environment is part of the value chain, this part must also be secured classically. Here, too, it is again the case that one’s own abilities in ​​safety must be assessed. A well-known representative of this type of attack is the Solarwinds Hack. Here, the build route was modified to compromise the newly created binary with each run. 

b.5) ​​Using Bad Dependencies – Dependency Thread

At this point, I would like to insert the dependency threads briefly. Dependencies are specifically modified and then offered. The security of the repositories plays a central role here. I’ll come back to that in a moment. However, this attack pattern refers to external locations where dependencies are fetched to process them. Particular attention should be paid to assessing the integrity of caches and mirrors of known official bodies. Often the “official” mirror servers of publicly accessible repositories do not have the same financial resources as the original. This causes attacks to be placed there.

You may be offered modified versions of known commonly used dependencies when you dock at such a place.

b.6) Bypassed CI/CD

Let’s get back to the build threads. Sometimes it is easier to bypass the CI/CD environment at an appropriate point. Here, the topics within a development path are selected where a transfer between the build server and the associated repositories is not sufficiently secured. The attack involves offering a recipient such as a repository a modified binary to make it look like it is from the CI environment. Malicious code is injected parallel to its own build infrastructure. 

b.7) Compromised package repo

A component repository is also part of the infrastructure and can fall victim to an attack. As with all other elements, protection is necessary here. Attackers try to gain access to the repositories to replace the binaries of known and frequently used dependencies with modified versions. Depending on your ability to harden such a system against attacks, you have to decide whether an externally managed alternative will increase the security standard of your value chain.

b.8) Using a bad package

We come to the last attack variant mentioned here. In this scenario, known dependencies are taken as a template and then their own modified versions are offered in a public repository. Here, an attempt is made to give the own variant a name close to the original name and depicts typical spelling errors. This dependency can still be resolved if a misspelling of the original name is used in a version definition. Only in this case a modified version of it will be loaded.

The only way to protect yourself against this attack is to carefully check how each individual dependency has been defined in your own projects. 

Project Persia Overview

We have seen which general types of attacks on a classic software development environment are possible. These are always generic attack patterns that can be used independently of the current products. Others also saw this as an idea to develop a general strategy to counter this. The language here is from the open-source project Persia, which is currently (early 2022) in the alpha phase. We are close to officially accepting it as an incubator in the CD Foundation. The project website is https://pyrsia.io.

The basic idea of ​​this project is that there will be a network of trust for open-source projects. A P2P network consisting of build and distribution nodes should exist where the sources are fetched, built and offered decentrally. In addition to the classic advantages such as reliability and better utilisation of the network resources of a P2P network, increased security should also be achieved with the binaries themselves. The types of attacks on source code management software are excluded. But all subsequent attack patterns can be repelled in this way. 

Unfortunately, it is not possible to fully describe the project. But at this point, I would like to draw attention to my video about this project. (https://pyrsia.io/) 

Cheers Sven

The Power of #JFrog Build Info (Build Metadata)

Posted on by Leave a comment

Intro

This article will take a detailed look at what the term build-info is all about and why it will help us protect against attacks such as the Solarwinds Hack. 

What is the concept behind the term – build-info?

Let’s start at the very beginning and clarify the basic principle behind the term build-info. The term build-info has been coined for many years by the company JFrog, among others. This is a particular type of repository.

This repository stores the information that describes the context that led to the creation of a binary file. With this information, you can now achieve a wide variety of things.

What components does build-info consist of?

The content of a build-info is not strictly defined. Instead, the approach that applies is that the more, the better. Of course, you have to proceed with caution here too. All possible parameters are collected. In addition to the date and time, the system on which the process was run, which operating system was used in which patch level, to active environment variables, compiler switches and library versions.

The challenge is actually that it is not known which information will later be helpful and expedient. For this reason, more rather than less should be saved.

Why do we actually need a build-info?

The task of a build-info is to enable the observation, or rather, the analysis of a past situation. There can be a variety of reasons for this. For example, it can be used to improve quality, or it can be the basis for reconstructing a cyber attack that has taken place. And with that, we come straight to the event that got everything rolling in the recent past.

Trigger – SolarWinds Hack

One of the others will have heard or read something about it. We are talking about one of the most significant cyberattacks that have ever taken place. It’s the SolarWinds Hack. Here it was not the final target that was attacked directly, but a point in the supply chain. SolarWinds is a software company that provides a product for managing network infrastructure. With just over 300,000 customers worldwide, this software’s automatic update process has been the target of the attack. It was not the update process itself that was compromised, but the creation of the binaries that will be distributed with this update process. The attack took place on the company’s CI route to immediately infect the newly created binaries with each build. Here the CI route was manipulated so that another component was added to the binary to be generated. This component can be thought of as a kind of initial charge. As soon as this has been ignited or activated, further components are dynamically reloaded. As a result, each infection had different forms. These files were then offered to all customers by means of an automatic update. Thus, over 15,000 systems were infiltrated within a short time.

Reaction – Executive Order of Cybersecurity

Since there were many well-known US companies, US organizations and US government institutions among the victims, the question arose of how to counter such a threat from the US state in the future. The US government has decided that one begins with the complete cataloguing of all software components in use, including all their constituent parts. This obligation to provide evidence was formulated in the “Executive Order of Cybersecurity”. However, when I first heard about an executive order, I wasn’t sure what that actually meant.

What is an executive order?

An executive order is a decree of the US President that regulates or changes internal affairs within the state apparatus. You can think of it as a US president like a managing director of a company who can influence his company’s internal processes and procedures. In doing so, no applicable law can be circumvented or changed. With such an executive order, no law can be changed, stopped or restricted. But it can change the internal processes of the US authorities very drastically. And that’s exactly what happened with this Executive Order of Cybersecurity, which has directly impacted the US economy. Every company that works directly or indirectly for the state must meet these requirements to continue doing business with the US authorities.

What is the key message of the Executive Order?

The Executive Order of Cybersecurity contains a little more text, the content of which I would like to shorten here and reproduce without guaranteeing legal correctness.

This arrangement aims to record the software operated by or for the US authorities in its entirety. This means that all components of the software used must be documented. This can be thought of as follows; If you want to bake a cake, you need a list of ingredients. However, listing these would not meet the requirements, as knowledge of all elements down to the last link is required. In our example, an ingredient that consists of more than one component would have to provide a list of all existing parts. This is how you get all the components used that are needed for the cake. If we now transfer this to the software, it is necessary to record all direct and indirect dependencies. The list of all components is then called – SBOM (Software Bills Of Material) 

And what does that mean for me?

Now I am not directly working for an organ of the US government. But it will still reach me sooner or later. Because through the indirection, all possible economic sectors worldwide will be affected. It can also affect me in the private sector. If I have an open-source project that is used indirectly in this environment, it can only continue if I prepare the project accordingly. Long story short; It will come our way in whatever way it will happen.

What are the general requirements for a build-info?

Let’s get back to the build-info. A build-info is a superset of an SBOM (Software Bills Of Material). So the dependencies are catalogued, and additional information from the runtime environment in which the binary is generated is recorded. However, there are also some requirements for such build-info. By this, I mean properties that must be present in order to be able to deal with this information in a meaningful way.

Accessibility:

The information that is collected must be quickly and easily accessible and therefore usable. A central storage location such as Artifactory is suitable here, as all binaries and dependencies are also stored here. You also have all the meta-information of a respective binary file at this location.

Immutability:

When information is collected, it makes sense to store it in such a way that it can no longer be changed. This promotes the acceptance of the data situation and gives particular security when evaluating a case.

Combinability:

The static data are also suitable for enriching them with current secondary data. In this case, I am talking about the vulnerabilities that can be found in the dependencies used. In contrast to the static information, this image has to be constantly updated. In practical use, this means that the data must be stored in a machine-readable manner in order to enable the connection of other data sources. In the case of Artifactory, it is the data from JFrog Xray that is displayed here.

How can a build-info be generated?

It would be best if you had the following things.

First, the JFrog CLI generates the build-info and second, it is possible to save this information permanently. You can do this very quickly with the Build-Info Repositories from Artifactory. But one step at a time.

The process for generating a build-info is as follows.

In the following example, we assume that we are going to build a Java project with maven. Here you have to get involved in the build process. You can do that quite easily with the JFrog CLI tools. These represent a wrapper for the build process used in each case. In our example, it is maven. To install the JFrog CLI Tools, you can go on the website https://jfrog.com/getcli/ choose the installer that is suitable for it. After installing and configuring the JFrog CLI Tools, you can start the build via the CLI on the command line. After a successful build, you can find the build-info as a JSON file in the target directory. This file can be viewed with a text editor to get a feel for the wealth of information that is stored here. This file is regenerated with each build. This means that there is a 1: 1 relationship between the build cycle and the binaries generated in the process. Using the CLI, you can then transfer this information to the Artifactory build repository and evaluate it there using a graphical user interface.

How can I link vulnerability scans to the build-info?

If you are now within Artifactory (https://bit.ly/SvenYouTube ), look at the build-information; you also get the current information regarding the known vulnerabilities. This is an example of how the build-information can be enriched with further system information.

Since there is not enough space at this point to clarify the generation and evaluation, I refer to a demo project in which I have stored the steps in the README, including detailed explanations of the individual practical steps.

If you want, you can also register for one of my free DevSecOps workshops. You are also welcome to speak to me directly if you’re going to do this in a free community or company event.

The URL for the demo project is: 

https://github.com/Java-Workshops/JFrog-FreeTier-JVM

Have fun trying it out.

Cheers, Sven! 

SolarWinds hack and the Executive Order from Mr Biden — And now?

Posted on by Leave a comment

In the past two years, we have had to learn a lot about cybersecurity. The new attack vectors are becoming more and more sophisticated and are directed more and more against the value chain in general. But what does that mean for us? What can be done about it, and what reactions have the state already taken?

Let’s start with the story that got all of this rolling and made sure that the general attention was drawn to the vulnerabilities of the available IT infrastructure. We’re talking about the SolarWinds Hack. What happened here, and what is more critical; What are the lessons learned from this incident?

It is essential to know that the SolarWinds company produces software that is used to manage network infrastructure. With the name “Orion Platform, ” this software should help manage and administer the network components efficiently. If you look at the product description on the SolarWinds website, you can read that the software can monitor, analyse, and manage the network infrastructure. And that’s exactly what the customers did. The company itself has around 300,000 customers worldwide, including individual companies and government organisations and corporations from a wide variety of areas. To always stay up to date, the software platform includes an automatic update mechanism. And that was exactly what the attackers were after. They saw in the SolarWinds company a multiplier for their own activities. But how can you go about this? The attackers obtained the necessary software tools by breaking into the FireEye company and infiltrating the SolarWinds network. The goal was the software development department in which the binaries of the Orion platform are created. Here, the CI routes have been manipulated to include compromised binaries in every build of the software. As a result, the company produced these binaries and put them into circulation through the automatic update process. In this way, around 18,000 targets could be infiltrated and compromised within a short time.

What does that mean for us now?

There are two angles here. The first is from the consumer’s point of view. However, for your own production, it must be ensured that no compromised binaries are used. That means that all, and here I mean all binaries used, must be checked. These are the dependencies of the application and the tools used in the production process. This includes the tools such as the CI server used, e.g. Jenkins, or the operating system components of the infrastructure and Docker images.

The second perspective represents the point of view that one has as a software distributor. This means anyone who distributes binaries in any form. This includes customers in the classic sense and other departments that may be considered consumers of the binaries created. The associated loss of trust can cause a company severe financial damage.

What can we do to protect ourselves?

If you look at the different approaches to arm yourself against these threats, you can see two fundamental differences.

DAST – Dynamic Application Security Testing

An application can be subjected to a black box test. This is called DAST, Dynamic Application Security Testing. Here you go the way a hacker would do it. The application is attacked via the available interaction points. Attack vectors based on the most common vulnerabilities are usually used here. SQL injection can be cited as an example. These attack patterns are initially independent of the technology used and represent typical security holes in web applications.

This approach has advantages as well as disadvantages. A serious disadvantage is that the tests cannot be started until the application has been developed. This means that the measures to eliminate weak points found are more costly than is the case with other approaches. On the other hand, a significant advantage of this approach is that the dynamic context can also be checked when testing the production system. Examples include weak configurations, open ports, and more.

SAST – Static Application Security Testing

The counterpart to the dynamic tests is the static tests. These tests analyse the individual components of the infrastructure involved. This includes not only the applications created but also the components involved in operating and creating the application.

A disadvantage of the SAST method is that it can only search for known security vulnerabilities. However, this point is put into perspective in that the number of known security gaps increases steadily. Still, it is also assumed that the number of known security gaps exceeds the number of unknown security gaps. Another advantage of the SAST method is that it checks the licenses used. This area also contributes to the security of the company, albeit in a legal sense.

So what has the most significant effect when you start with the topic of security?

When looking at the different approaches, it becomes clear that the proportion of directly or indirectly used binaries makes up the most significant amount in a technology stack. This means that you should also start securing precisely these parts. Unfortunately, there is only one way to ensure with SAST that it is really 100% checked directly. All other methods do not achieve this coverage, or if they do, then only in sporadic exceptional cases.

However, it should be noted that one understands the interdependencies. This is the only way to identify and extract the possible attack vector. Here it is of essential importance that not only the binaries themselves are examined, but also the associated meta-information is evaluated. Within software development, there are two points for these analyses where such an analysis fits very well. The first point that most people will think of is the CI segment. Here the CI server can carry out the analysis during the execution of a build pipeline and all the checks and also take over the reporting. If the violations are too massive, the build is cancelled. The second position, which is ideally suited for such an analysis, is directly in the IDE. Here it can already be determined during the definition whether the license used is permitted. The known vulnerabilities can also be extracted and thus provide enough information to decide whether this version of this dependency may be used.

Lesson Learned – what we learned from the SolarWinds Hack.

We learned the following things from SolarWinds. First, the attacks are no longer aimed at the final targets themselves but against the suppliers. Here one tries to reach multipliers who massively increase the effectiveness of this attack. Likewise, you no longer only have to protect yourself against your use of compromised binaries. The newly added component means that the self-generated binaries must also be secured. Nobody wants to become a distributor of infected software. It follows that all parts involved must be subjected to permanent checks.

Reactions – The Executive Order from Mr Biden

One or the other has undoubtedly noticed that the US President gave this Executive Order of Cybersecurity. But what exactly does that mean, and who can even do something like that under what conditions?

In the United States, the president – the “executive branch” of the US government – can issue what is known as an executive order. Much like a CEO in a company, the executive branch has the power to make some unilateral decisions that affect the behaviour of the US government. These orders must be limited to government conduct and policies and not to general laws or statutes that encroach on the rights of any individual or state. If the executive transgresses in this area, the US Supreme Court or other legal remedies can appeal and revoke all measures. Only the president – due to his status as head of state – can issue an executive order. No other officer is allowed to do this.

Significantly, executive orders are mostly limited to how the US government operates internally. For example, an executive order might not simply resolve to raise taxes in a state or issue far-reaching commercial guidelines. However, executive orders are legally binding on the behaviour of the US government if they do not violate fundamental rights or make something unconstitutional. Because of this, these commands can be found to change the policy from the president to the president as, like a CEO, they set some of the government’s agendas. In this case, the Executive Ordinance refers to how the US government monitors and regulates its software usage and sets out requirements for how that software must be documented to be sold to the government. It doesn’t dictate trading on a broad scale.

Since the US government can define its way of working, it was decided that the SBOM requirements (in preparation) will be the only way to approve software purchases – to get an idea of ​​the volume, you have to know it is one amount in the tens of billions per year. This means that any company that wants to sell to US government agencies, likely state and local agencies, and anyone who works with resellers who sell to the government and more, must meet all of these new standards.

When the European Union agreed on comprehensive data protection and data security laws with the GDPR, the effect was felt worldwide and quickly. In a globally networked economy, decisions by the world’s largest GDP producers can set standards for other areas. With the GDPR, companies in the US and elsewhere had to immediately revise and update software and processes to continue doing business in the EU. It became a worldwide rule so as not to lose EU treaties. Likewise, the US cybersecurity order is believed to be reversing, with U.S.-based global corporations influencing global software security behaviour.

Wow – what now?

What does that mean for me as a software developer? Well, the effects at this point are not as severe as you might want to imagine. In the end, it is said that a complete list of all contained dependencies must be created. This means the direct and indirect dependencies. To obtain such a dependency graph, one can, for example, use the tools that already do this. It means the tools that can generate a complete dependency graph, for example. For this, you need a logical point through which all dependencies are fetched. A tool such as Artifactory is best, as this is where the knowledge of all dependency managers used comes together. Devices such as the vulnerability scanner JFrog Xray can then access this information, scan for known vulnerabilities and licenses used, and extract the entire dependency graph. This information can thus be generated as build information by the CI route (e.g. JFrog Pipelines) and stored in a build repository within Artifactory.

Conclusion

We have seen that the new qualities of attacks on software systems, in general, will lead to advanced countermeasures. What is meant here is a complete analysis of all artefacts involved and produced. The tools required for this must combine the information into aggregated impact graphs across technology boundaries. One point within software development that is ideal for this is the logical point via which all binaries are fed into the system. However, the components alone are insufficient since all indirect elements can only be reached and checked by understanding the associated meta-information.

The tools used for this can then also be used to create the SBOMs.

In my opinion, it is only a matter of time before we also have to meet this requirement if we do not want to suffer economic disadvantages from the Executive Order of Cybersecurity.

If you want to find out more about the topic or test the tools briefly mentioned here, don’t hesitate to contact me.

In addition to further information, we at JFrog offer free workshops to prepare for these challenges in a purely practical manner.

And if you want to know more immediately, you are welcome to go to my YouTube channel. There I have other videos on this topic.

It would be nice to leave a subscription on my YouTube channel as a small thank you. https://www.youtube.com/channel/UCNkQKejDX-pQM9-lKZRpEwA

Cheers Sven

What is the difference between SAST, DAST, IAST and RASP?

Posted on by Leave a comment

Intro:

In this post, we’re going to look at the differences between the various cybersecurity defence techniques. Here you can identify four main groups, which we will go through briefly one after another to illustrate the advantages and disadvantages.

SAST – Static Application Security Testing

SAST describes the process in which the components of an application are subjected to a static analysis. This approach not only searches for security gaps but also determines the licenses for the individual elements. In the following, however, I will only deal with the consideration of vulnerabilities in this post.

The term static comes from the fact that only the static context is used for this evaluation. All dynamic or context-related assessments are not possible with this method. SAST can be used to analyze the entire tech stack of an application if access to these components is possible, which is also one of the advantages of SAST compared to other analysis methods. The only exception is the IAST procedure, which we will come back to later.

What exactly happens now with the SAST procedure? SAST is available in two forms. The first that I would like to mention relates to checking your source code. Here the attempt is made to determine whether there are patterns that make a later vulnerability easier or even possible in the first place. For example, it searches for calls to critical libraries or identifies unsafe handling of resources. However, one honestly has to admit at this point that, first of all, your source code will be by far the smallest part of the overall application in the vast majority of projects. Second, the analysis methods in this area are still at a very early stage of development.

When using SAST, it makes a lot more sense to deal with all the other components first. Therefore, all binary files of the entire application environment are meant here. This also includes all elements that play a role in the development, such as the CI server and the other tools used.

DAST – Dynamic Application Security Testing

The DAST analysis method does precisely the opposite in comparison to the SAST method. Here the application is viewed as a black box. As soon as an executable version of the application is available, it is attacked through automatically executed cyber attacks. In most cases, the general attack patterns are based on the Most Common Vulnerabilities defined by the OSWAP. Defining your attack vectors is either not provided for in the tools I know or requires very detailed knowledge in this area. For developers who do not use these tools daily and intensively, their use is limited to the predefined attack vectors. It is a good thing with this procedure that unknown security gaps can also be identified, as long as they are based on the Most Common Vulnerabilities. Some manufacturers extend this approach with AI or ML techniques. This approach using AI and ML techniques is still in a very early stage of development, and the currently available potential cannot be foreseen.

Unfortunately, the method can only be used sensibly against the production environment, as this is the only way to identify all gaps based on configuration deficiencies. Therefore, in contrast to the SAST process, it makes no sense to use it within the CI route.

IAST – Interactive Application Security Testing

IAST uses software tools to evaluate application performance and identify vulnerabilities. IAST takes an “agent-like” approach; H. Agents and sensors run to continuously analyze application functions during automated tests, manual tests, or a mixture of both.

The process and feedback occur in real-time in the IDE, Continuous Integration (CI) environment or quality assurance or during production. The sensors have access to:

  • All source code
  • Data and control flow
  • System configuration data
  • Web components
  • Backend connection data

The main difference between IAST, SAST, and DAST is that it runs inside the application.

Access to all static components as well as the runtime information enables a very comprehensive picture.

It is a combination of static and dynamic analysis. However, the part of the dynamic analysis is not a pure black-box test as it is implemented at DAST.

Some reasons for using IAST:

Potential problems are identified earlier, so IAST minimizes the cost of eliminating potential costs and delays.

This is due to a “shift left” approach, meaning it is carried out in the early stages of the project life cycle.

Similar to SAST, the IAST analysis provides complete lines of data-rich code so that security teams can immediately lookout for a specific bug.

With the wealth of information that the tool has access to, the source of vulnerabilities can be precisely identified.

Unlike other dynamic software tests, IAST can be easily integrated into Continuous Integration and Deployment (CI / CD) pipelines.

The evaluations take place in real-time in the production environment.

On the other hand:

IAST tools can slow down the operation of the application.

This is based on the fact that the agents change the bytecode themselves. This leads to a lower performance of the overall system.

The change itself can, of course, also lead to problems in the production environment.

The use of agents naturally also represents a potential source of danger since these agents can also be compromised.

– See Solarwinds Hack

RASP – Runtime Application Self Protection

RASP is the approach to secure the application from within.

The backup takes place at runtime and generally consists of looking for suspicious commands when they are executed.

What does that mean now?

With the RASP approach, you can examine the entire application context on the production machine and real-time.

Here all commands that are processed are examined for possible attack patterns.

Therefore, this procedure aims to identify existing security gaps and attack patterns and those that are not yet known.

Here it goes very clearly into the use of AI and ML techniques.

RASP tools can usually be used in two operating modes.

The first operating mode (monitoring) is limited to observing and reporting possible attacks.

The second operating mode (protection) then includes implementing defensive measures in real-time and directly on the production environment.

RASP aims to fill the gap left by application security testing and network perimeter controls.

The two approaches (SAST and DAST) do not have sufficient visibility into real-time data and event flows to prevent vulnerabilities from sliding through the verification process or block new threats that were overlooked during development.

RASP is similar to Interactive Application Security Testing (IAST); the main difference is that IAST focuses on identifying vulnerabilities in the applications, and RASPs focus on protecting against cybersecurity attacks that can exploit these vulnerabilities or other attack vectors.

The RASP technology has the following advantages:

First, RASP complements SAST and DAST with an additional layer of protection after the application is started (usually in production).

It can be easily applied with faster development cycles.

Unexpected entries are checked and checked.

It enables you to react quickly to an attack by providing comprehensive analysis and information about the possible vulnerabilities.

However, RASP tools have certain disadvantages:

By sitting on the application server, RASP tools can adversely affect application performance.

In addition, the technology (RASP) may not be compliant with regulations or internal guidelines,

which allows the installation of other software or

the automatic blocking of services is permitted.

The use of this technology can also lead to the people involved believing themselves to be false security.

The application must also be switched offline until the vulnerability is eliminated.

RASP is not a substitute for application security testing because it cannot provide comprehensive protection.

While RASP and IAST have similar methods and uses, RASP does not perform extensive scans but instead runs as part of the application to examine traffic and activity. Both report attacks as soon as they occur; with IAST, this happens at the time of the test, while with RASP, it takes place at runtime in production.

Conclusion

All approaches result in a wide range of options for arming yourself against known and unknown security gaps. Here it is essential to reconcile your own needs and those of the company for the future direction.

Conclusion RASP:

We have seen that with RASP, there is an approach in which the application can protect itself against attacks at runtime. The permanent monitoring of your activities and the data transferred to the application enable an analysis based on the runtime environment. Here you can choose between pure monitoring or alerting and active self-protection. However, software components are added to the runtime environment with RASP approaches to manipulate the system independently. This has an impact on performance. With this approach, RASP concentrates on the detection and defence of current cyber attacks. So it analyzes the data and user behaviour in order to identify suspicious activities.

Conclusion IAST:

The IAST approach combines the SAST and DAST approach and is already used within the SDLC, i.e. within the development itself. This means that the IAST tools are already further “to the left” compared to the RASP tools. Another difference to the RASP tools is that IAST consists of static, dynamic and manual tests. Here it also becomes clear that IAST is more in the development phase. The combination of dynamic, static and manual tests promises a comprehensive security solution. However, one should not underestimate the complexity of the manual and dynamic security tests at this point.

Conclusion DAST:

The DAST approach focuses on how a hacker would approach the system. The overall system is understood like a black box, and the attacks occur without knowing the technologies used. The point here is to harden the production system against the Most Common Vulnerabilities. However, one must not forget at this point that this technology can only be used at the end of the production cycle.

Conclusion SAST:

If you have access to all system components, the SAST approach can be used very effectively against known security gaps and license problems. This procedure is the only guarantee that the entire tech stack can be subjected to direct control. The focus of the SAST approach is on static semantics and, in turn, is completely blind to security holes in the dynamic context. A huge advantage is that this approach can be used with the first line of source code.

My personal opinion:

My personal opinion on these different approaches is as follows:

If you start with DevSecOps or security in IT in general, the SAST approach makes the most sense. This is where the greatest potential threat can be eliminated with minimal effort. It is also a process that can be used in all steps of the production line. Only when all components in the system are secured against known security gaps do the following methods show their highest potential. After introducing SAST, I would raise the IAST approach and, finally, the RASP approach. This also ensures that the respective teams can grow with the task and that there are no obstacles or delays in production.

Cheers Sven

The Lifeline of a Vulnerability

Posted on by Leave a comment

Intro

Again and again, we read something in the IT news about security gaps that have been found. The more severe the classification of this loophole, the more attention this information will get in the general press. Most of the time, you don’t even hear or read anything about all the security holes found that are not as well known as the SolarWinds Hack, for example. But what is the typical lifeline of such a security gap?

Vulnerability was generated until found 

Let’s start with the birth of a vulnerability. This birth can be done in two differently motivated ways. On the one hand, it can happen to any developer that he creates a security hole by an unfortunate combination of source code pieces. On the other hand, it can also be based on targeted manipulation. However, this has essentially no effect on the further course of the lifeline of a security vulnerability. In the following, we assume that a security hole has been created and that it is now active in some software. These can be executable programs or libraries offered that are integrated into other software projects as a dependency.

Found until Public available

In most cases, it is not possible to understand precisely when a security hole was created. But let’s assume that there is a security hole and that it will be found. It clearly depends on which person or which team finds this weak point. This has a severe impact on the subsequent course of history. Let’s start with the fact that this vulnerability has been found by people who are interested in using this vulnerability themselves or having it exploited by other parties. Here the information is either kept under lock and key or offered for purchase at relevant places on the Internet. There are primarily financial or political motives here, which I do not want to go into here. However, at this point, it can be clearly seen that the information is passed on at this point in channels that are not generally available to the public.

However, if the security gap is found by people or groups who are interested in making the knowledge about it available to the general public, various mechanisms now take effect. However, one must not forget that commercial interests will also play a role in most cases. However, the motivation is different. If the company or the project itself is affected by this vulnerability, there is usually an interest in presenting the information relatively harmless. The feared damage can even lead to the security gap being fixed, but knowledge about it further is hidden. This approach is to be viewed as critical, as it must be assumed that there will also be other groups or people who will gain this knowledge.

But let’s assume that people who are not directly involved in the affected components found the information about the vulnerability. In most cases, this is the motivation to sell knowledge of the vulnerability. In addition to the affected projects or products, there are also providers of the vulnerability databases. These companies have a direct and obvious interest in acquiring this knowledge. But to which company will the finder of the vulnerability sell this knowledge? Here it can be assumed that there is a very high probability that it will be the company that pays the better price. This has another side effect that affects the classification of the vulnerability. Many vulnerabilities are given an assessment using the CVSS. Here, the base value is made by different people. Different people will have other personal interests here, which will then also be reflected in this value. 

Here I refer to the blog post about CVSS – explained. https://svenruppert.com/2021/04/07/cvss-explained-the-basics/

Regardless of the detours via which the knowledge comes to the vulnerabilities databases. Only when the information has reached one of these points can one assume that this knowledge will be available to the general public over time.

Public available until consumable

However, one fact can be seen very clearly at this point. Regardless of which provider of vulnerabilities you choose, there will only ever be a subset of all known vulnerabilities in this data set. As an end consumer, there is only one sensible way to go here. Instead of contacting the providers directly, you should rely on integrators. This refers to services that integrate various sources themselves and then offer them processed and merged. It is also essential that the findings are processed so that further processing by machines is possible. This means that the meta-information such as the CVE or the CVSS value is supplied. This is the only way other programs can work with this information. The CVSS value is given as an example. This is used, for example, in CI environments to interrupt further processing when a particular threshold value is reached. Only when the information is prepared in this way and is available to the end-user can this information be consumable. Since the information generally represents a considerable financial value, it can be assumed in the vast majority of cases that the commercial providers of such data sets will have access to updated information more quickly than freely available data collections.

Consumable until running in Production

If the information can now be consumed, i.e. processed with the tools used in software development, the storyline begins in your projects. Whichever provider you have decided on, this information is available from a particular point in time, and you can now react to it yourself. The requirement is that the necessary changes are activated in production as quickly as possible. This is the only way to avoid the potential damage that can result from this security vulnerability. This results in various requirements for your software development processes. The most obvious need is the throughput times. Only those who have implemented a high degree of automation can enable short response times in the delivery processes. It is also an advantage if the team concerned can make the necessary decisions themselves and quickly. Lengthy approval processes are annoying at this point and can also cause extensive damage to the company.

Another point that can release high potential is the provision of safety-critical information in all production stages involved. The earlier the data is taken into account in production, the lower the cost of removing security gaps. We’ll come back to that in more detail when the shift-left topic is discussed.

Another question that arises is that of the effective mechanisms against vulnerabilities.

TestCoverage is your safety-belt; try Mutation Testing

The best knowledge of security gaps is of no use if this knowledge cannot be put to use. But what tools do you have in software development to take efficient action against known security gaps? Here I would like to highlight one metric in particular: the test coverage of your own source code parts. If you have strong test coverage, you can make changes to the system and rely on the test suite. If a smooth test of all affected system components has taken place, nothing stands in the way of making the software available from a technical point of view.

But let’s take a step back and take a closer look at the situation. In most cases, changing the version of the same dependency in use will remove known vulnerabilities. This means that efficient version management gives you the agility you need to be able to react quickly. In very few cases, the affected components have to be replaced by semantic equivalents from other manufacturers. And to classify the new composition of versions of the same ingredients as valid, strong test coverage is required. Manual tests would go far beyond the time frame and cannot be carried out with the same quality in every run. But what is strong test coverage?

I use the technique of mutation testing. This gives you more concrete test coverage than is usually the case with the conventional line or branch coverage. Unfortunately, a complete description of this procedure is not possible at this point.

However, if you want to learn more about mutation testing, visit the following URL. This video explains the theoretical and practical part of the mutation test for Java and Kotlin.

The need for a single point that understands all repo-types

If we now assume that we want to search for known security vulnerabilities in the development and the operation of the software, we need a place where we can carry out the search processes. Different areas are suitable here. However, there is a requirement that enables an efficient scan across all technologies used. We are talking about a logical central point through which all binaries must go. I don’t just mean the jar files declared as dependencies, but also all other files such as the Debian packages or Docker images. Artifactory is suitable for this as a central hub as it supports pretty much all package managers at one point. Because you have knowledge of the individual files and have the metadata, the following things can also be evaluated.

First of all, it is not only possible to capture the direct dependencies. Knowing the structures of the package managers used means that all indirect dependencies are also known. Second, it is possible to receive cross-technology evaluations. This means the full impact graph to capture the practical meaning of the individual vulnerabilities. The tool from JFrog that can give an overview here is JFrog Xray, and we are directly connected to JFrog Artifactory. Whichever tool you choose, it is crucial that you don’t just scan one technology layer. Only with a comprehensive look at the entire tech stack can one guarantee that there are no known security gaps, either directly or indirectly, in production.

Conclusion

Now we come to a conclusion. We have seen that we have little influence on most sections of a typical lifeline of an IT security vulnerability. Actually, there are only two sections that we can influence directly. On the one hand, it is the quickest and most comprehensive possible access to reliable security databases. Here it is essential that you not only entrust yourself to one provider but rather concentrate on so-called “mergers” or “aggregators”. The use of such supersets can compensate for the economically motivated vagueness of the individual providers. I named JFrog Xray as an example of such an aggregator. The second section of a typical lifeline is in your own home. That means, as soon as you know about a security gap, you have to act yourself—robust automation and a well-coordinated DevSecOps team help here. We will deal with precisely this section from the “security” perspective in another blogpost. Here, however, we had already seen that strong test coverage is one of the critical elements in the fight against vulnerabilities. Here I would like to refer again to the test method “Mutation Testing”, which is a very effective tool in TDD.

And what can I do right now?

Aou can, of course, take a look at my YouTube channel and find out a little more about the topic there. I would be delighted to welcome you as my new subscriber. Thanks!

https://www.youtube.com/@OutdoorNerd

Happy Coding

Sven