Uniting our expertise, Checkmarx and Mobb partnered more than a year ago, and our collaboration benefits developers, AppSec managers, and CISOs alike as we work to build #DevSecTrust and power the transition to DevSecOps. 

Checkmarx customers can now deploy Mobb’s auto-remediation solution for vulnerabilities identified during scans with CxSAST (on-prem solution) and the Checkmarx One platform. This partnership significantly reduces the time and cost involved in remediating vulnerabilities and bridges the gap between developers and security in two key ways:

1. Checkmarx’ industry leading SAST solution is highly tuned for accuracy and prioritizes findings to minimize the noise that enters the developer workflow in the first place. Developers trust that the alerts represent genuinely material, exploitable problems and they know what to fix first.
2. Mobb’s AI engine provides auto-remediation of the vulnerabilities identified by Checkmarx in just a few clicks – there’s no need for developers to review scan reports and search for fixes and fix locations. This means they can focus on innovation.

Auto-remediation can be easily integrated into the CI/CD pipeline or triggered as part of manual scans, guiding developers to fix vulnerabilities quickly and seamlessly.

How it works: AI-powered auto-remediation for code vulnerabilities

Mobb’s auto-remediation solution is provided by its AI engine and heuristics based on known best practices for the most common vulnerability types and the most common programming languages.

For example, a workflow can start when the developer commits their code changes to GitHub. A Checkmarx SAST scan is initiated as part of the CI/CD workflow. Once the scan is complete, Mobb analyzes the findings and identifies all instances of supported issues. It extracts all the information it needs to fix each finding automatically and then analyzes the vulnerabilities and the developer’s source code for essential contextual information on how the error was created. Mobb then matches its pre-prepared fix algorithms to each context and the algorithm builds the correct fix. The vulnerability and proposed fix is flagged to the developer, showing the fix side-by-side with the vulnerable code. Once the developer approves the fix, it is made automatically. Once the fixed code branch is merged with the main code, the Checkmarx scan can be re-run to verify that the fix is implemented. Watch how simple the process is here.

For the developer experience, this is game-changing. Instead of having to read and analyze a vulnerability report with details about the vulnerabilities and suggestions on how to fix it, they get an instant fix provided; a pull request is ready, and they just need to merge the fixed code and move on. The reduction in friction combined with trust in the accuracy of Checkmarx scans means they can incorporate security more easily into their workflow, so productivity stays high.

CISO, AppSec team, and business benefits

From a CISO perspective, auto-remediation offers a force multiplier in the reduction of vulnerability backlogs by allowing developers to  easily address them earlier in the development process. AppSec teams can streamline policies and processes and get code into production faster, without compromising on security.

Across the board, Checkmarx and Mobb save the business money, by identifying only material and  exploitable vulnerabilities while providing the fastest way to a recommended fix. This dramatically reduces the amount of time developers need to manage security responsibilities.
Checkmarx is committed to pushing the boundaries of the developer experience and this solution builds on Checkmarx’s existing auto-remediation solutions for SCA and IaC vulnerabilities. Together these help developers and AppSec teams deliver secure software fast.

Powerful partnerships drive secure software excellence

The Checkmarx partnership ecosystem is designed to bring Checkmarx customers the most advanced solutions to complement its industry-leading AppSec platform and help them secure the code base without compromising on productivity. 

Mobb is already making an impact in the market and won the Startup Spotlight competition at Black Hat USA in August 2023. Mobb’s deep understanding of the challenges of implementing DevSecOps makes it an ideal Checkmarx partner and we are looking forward to building further on our solutions together.

Getting started

Checkmarx customers can leverage Mobb’s auto-remediation solution by talking with their account team. 

For more information get in touch with your Checkmarx account rep or contact us today.

We’re so excited to launch support for ServiceNow customers, given the growing need for streamlined, end-to-end vulnerability management. 

Let’s dive a bit deeper into what Checkmarx and ServiceNow customers can expect from the integration.   

Prioritize and remediate with a centralized dashboard  

ServiceNow is a leading cloud-based platform that offers comprehensive solutions for IT service management, human resources, customer service, security operations, and more. It enables organizations to automate workflows, optimize processes, and provide seamless digital experiences to users across multiple departments. 

The ServiceNow® Vulnerability Response application is an important tool within the ServiceNow ecosystem that AppSec managers can leverage to drive efficiencies within application security. 

This application imports and automatically groups vulnerable items according to group rules, which allows teams to remediate vulnerabilities quickly. Data is pulled from both internal and external sources, such as the National Vulnerability Database (NVD) and third-party integrations, like the new Checkmarx plugins. 

The ServiceNow Application Vulnerability Response dashboard displays trends and summaries of vulnerabilities from leading scan vendors like Checkmarx.  

The Checkmarx ServiceNow Vulnerability Integration is now available for Checkmarx SAST and Checkmarx SCA. The integration for Checkmarx SAST is available for both Checkmarx One and on-premise deployments, while SCA is available for Checkmarx One.  

The plugins enable enterprises to run the integrations required to import projects, scan summaries, and scan results within the ServiceNow platform, giving your application security managers a clear view and top-tier prioritization and triage powers. The latest vulnerabilities found for each scan are then inserted on the ServiceNow as Application Vulnerability Items (AVIs). 

The plugins do not scan code; instead, they pull data from Checkmarx and map the results into the ServiceNow tables.  

ServiceNow Vulnerability Solutions Management: View your organization’s most impactful remediation activities and monitor their completion. 

Every time Checkmarx provides updated scan results, the ServiceNow Vulnerability Response Application can automatically assign the found vulnerabilities to a specific person, or team, by building custom workflows and automation triggers. This process accelerates the security workflow, ensuring an efficient vulnerability management process. 

Use Application Vulnerability Response to follow the flow of information, from integration through investigation, and then on to resolution. 

After vulnerability data is imported, users can compare the data to applications identified in Application Vulnerability Response, relate a single third-party vulnerability to multiple CWE entries, and find the primary CWE for the vulnerability in determining risk. And, users can easily prioritize vulnerabilities by create assignment rules or using calculators to determine business impact.   

Getting started  

With the addition of ServiceNow to the growing list of Checkmarx integrations, we’re making our products as compatible as possible with business-critical applications, so organizations can optimize workflows and keep their own applications secure.  

For customers already using both ServiceNow + Checkmarx One or Checkmarx SAST, head over to the ServiceNow Store to download the app.  

Checkmarx One Vulnerability Integration with ServiceNow (Checkmarx SAST and Checkmarx SCA)  

Download the app  

View the documentation  

Checkmarx SAST On-Prem Vulnerability Integration with ServiceNow 

View the documentation  

For existing ServiceNow customers that would like to learn more about the accuracy and power of Checkmarx One, especially how to easily view and triage scan results within ServiceNow, contact us today.  

Wrap up  

Vulnerability risk management is crucial for organizations to protect their IT infrastructure from cyber threats and to comply with regulatory requirements.  

By integrating Checkmarx scan results into the ServiceNow Vulnerability Response Application, users can better manage vulnerabilities and ensure seamless communication with incident response tasks, change requests, and problem management.  

We’re so excited to announce this integration and can’t wait to hear from more customers about the day-to-day impact it makes on building smart and efficient workflows and the ability to better track, prioritize, and remediate the vulnerabilities in one centralized dashboard.  

The Go Programming Language (also known as Golang) is an open source programming language created by Google. Go is compiled and is statically typed as in C (with garbage collection). It has limited structural typing, memory safety features, and CSP-style concurrent features. In this article, I will cover Go Race Conditions from theory to practice including source code examples. I will discuss how to detect and solve race condition issues and the security impact they represent.

The theory

Race conditions are a common issue in software due to a computer program that expects a sequence of operations to execute in a specific order, but they run in another, making the software output unpredictable. These issues are common in concurrent computer programs where either multiple workers, processes, or threads shared a state.
On one hand, these issues are quite easy to introduce during the software development stage since concurrency is not easy to accomplish. On the other hand, they are difficult to detect/debug since the computer program behavior won’t always be deterministic.
For example, think about HTTP servers in general. They are a great example of concurrent computer programs since they are able to consistently handle simultaneous requests. For example, to track the number of visits/visitors to a web page, we can use a file on a local file system. When a new HTTP request is received, the process reads the current counter value from this file, increments it by 1, and writes the new value to the same file. Let’s explore this example in the next section.

In Practice

Let’s start by writing our HTTP server main() function, using Go http package

Now, we’ll implement the updateVisitsCounter() function, which is responsible to read/write the number of visits from/to a file in the filesystem. Please notice that error handling is missing for brevity.

The full source code can be found here. To run it, enter go run server.go and point your browser to https://localhost:8080. You should expect to see the visitor number increase every time the browser window is reloaded as shown below.

Figure 1

While running the server locally, with a single user accessing it, you should not experience the race condition. To make the race condition noticeable, let’s stress the server a little with a few concurrent HTTP requests. We can accomplish this by running concurrent-requests.go as shown in Figure 2.

Figure 2
On the left side of Figure 2, server.go is running and ready to receive requests. On the right side, the concurrent-requests.go will make 5 concurrent HTTP requests to it. Each output line starts with the request timestamp (Time.UnixNano()) and the request’s response.
Clearly, the output on the right side is not the expected one: four distinct requests received the same message, “Hello, you’re visitor #1”.
Notice that visitor #3, #4 and #5 are missing in Figure 2. Sorting the output by timestamp, we see that after visitor number #2 there were three other visitors who received the message, “Hello, you’re visitor #1”, as shown in Figure 3.

Figure 3
As explained in the previous section, our HTTP server implementation has:

1. a shared state: the file in the filesystem where the counter is persisted (VISITS_COUNTER_FILE) and
2. updateVisitsCounter() implementation expects read/write operations from/to the file in the filesystem to happen sequentially and in this strict order.

Figure 4 below illustrates the race condition with two concurrent workers: (worker1 and worker2)

Figure 4
Both workers read the value 0 (zero) from VISITS_COUNTER_FILE. Then worker1 updates the value to 1. While worker2 is still processing its first request, worker1 receives a new request doing a read immediately followed by a write operation, updating VISITS_COUNTER_FILE to 2. When worker2 finishes handling the request, it writes to VISITS_COUNTER_FILE the value 1: the read value 0 (zero) incremented by one unit. Finally, worker1 receives a new request, reading the VISITS_COUNTER_FILE, whose value is 1.

Security impact

Race conditions can be exploited to cause software malfunctioning, leading to problems such as Denial of Service and Privilege Escalation. Time of check to time of use (TOCTTOU) is a class of race conditions that may lead to privilege escalation.
Below are some examples of race conditions:

• Window Open Race Condition Vulnerability, Internet Explorer, CVE-2011-1257
• Windows Shortcut-Link, CVE-2010-2568
• Pulse Audio, CVE-2009-1894
• Firefox, CVE-2007-5960

How to detect

As previously mentioned, it isn’t easy to find and solve race conditions, but care, diligence, and testing will certainly help. Despite of offering a clean way to write concurrent code, Go creators felt the need to add a race detector to help diagnose race conditions.
Go race detector works on all major operating systems, but only on 64bits systems, and it can only detect data races (accesses to memory from different threads or operations that impose ordering on memory accesses). Remember that race condition detection happens at runtime with a cost of 5-10x in memory increase, and 2-20x in execution time for a typical program.
To enable races detection, run your programs with the -race option, e.g., go run -race server.go. Go race detector won’t report any races on server.go because it isn’t a data race but, instead, a TOCTTOU race. Changing the implementation, replacing the VISITS_COUNTER_FILE file by a shared global variable visitsCounter to store number of visits (server-alternative.go), will allow us to see -race option output go run -race server-alternative.go as shown in Figure 5 below.

Figure 5

How to solve

Generally speaking, using mutual exclusion locks (mutex), semaphores, and other access and execution control primitives will help you preventing races. Packages like sync provides basic synchronization primitives such as mutual exclusion locks.
Adding a mutex to our HTTP server as in server-fixed.go implementation, fixes the race condition, leading to the expected result as shown in Figure 6.

Figure 6
Mutual exclusion locks role in computer programs is very simple. Before starting an operation on shared state, one worker should gain access to it acquiring mutex’s lock (Lock()). As soon as it happens, all other workers willing to manipulate the shared state will be blocked until the mutex’s lock is released (Unlock()). Once the mutex’s lock is released, the next worker will be able to manipulate the shared state.
In our example, acquiring mutex’s lock will enable the worker to read and write from/to the VISITS_COUNTER_FILE in this exact order, without interference from other workers. After updating the VISITS_COUNTER_FILE, then other workers will be able to do the same.
Of course, access and execution control primitives bring other challenges. For example, what if mutex’s lock never gets released? Workers will be perpetually denied access to the shared resource, potentially leading to a Denial of Service. This is a well-known problem in concurrent programming called starvation, which is out of the scope of this blog post.

Conclusion

Golang concurrency is awesome but there’s not much the compiler can do to prevent you from making mistakes leading to a Race Condition. Race conditions are something you’ll really want to avoid, and detection and debugging are both tough tasks.
While writing concurrent programs double check whether state (e.g., a file or variable) is accessed by more than one worker/thread/process at the same time. If so, you’ll need some access control mechanism such as mutexes or semaphores.

References

• Go Security Coding Practices
• Time of check to time of use
• Go Data Race Detector
• Go memory model
• Go synx package
• Race Condition Exploits
• Starvation