Keeping Up with the Changing Pace of Development

In the past, software development mainly followed a waterfall approach- releasing software only once or twice a year. But the world has changed. Nowadays, cloud-native development often means releasing updates multiple times a day. This change in pace of application development has made speed a more important consideration. Sometimes, this comes at the expense of security. In Checkmarx’s upcoming survey on the state of application security, 91% of respondents even admitted to deploying vulnerable code to production. It’s no longer about finding everything but finding and fixing what matters most.

Up until now, companies had to choose — a developer-oriented SAST tool that risked false negatives – vulnerable code never being identified and unknowingly released into production – or security-oriented solutions which found everything, but often at the expense of speed and had false positives, making it difficult for developers to know what to fix before the next sprint.

Either/Or. Not both.

This led to further solution sprawl, as companies sometimes used an array of tools for their team – a “good enough” solution for less mature teams and enterprise-grade solution for their enterprise teams.

Until now. 

We are pleased to announce that our new SAST scanning engine will further improve an individual’s ability to customize their scanning capabilities, and experience speed, accuracy, and security.

Risk Reduction vs Ease of Use – Do I Have To Choose One?

Traditional SAST offerings force customers to choose between maximum risk reduction and ease of use (which finds less risk). 

With this new release, Checkmarx is the only solution that offers both in a single package, providing enterprises with the power and flexibility to secure their entire application footprint, and enabling a better developer experience

The new engine offers both in-depth security (to find maximum risk) and fast scanning (to cover every application with minimum overhead and noise). Users can choose the most appropriate configuration for each application based on that application’s requirements:

• Fast scanning to cover more applications to showcase relevant results faster
• In-depth scanning to find the maximum risk in critical applications with high business risk

I Already Have Checkmarx SAST. How do I Take Advantage of This?

If you already use Checkmarx’s SAST (whether on-prem or Checkmarx One), you can take advantage of these new capabilities today. It’s very easy to set this up (here’s how on the account and project level in Checkmarx One /  project level on CxSAST) Contact your account manager for more help or to have them walk through this with you.

The Best of Both Worlds: Development and Security Approved

This fast scan mode allows developers more flexibility in their fast-paced environment where they are constantly writing and updating code. They need scanning capabilities that can keep up with short sprints and continuous deployment by providing scanning that is exceptionally fast and provides only the most relevant results. Different apps have different risk-levels and criticality. Our new fast scan mode allows developers the ability to scan more frequently while highlighting the most relevant results so that they can focus on remediating the most important vulnerabilities. But, for mission critical apps, organizations can pick in-depth scan mode and get deeper scans and stronger correlation.

To further increase alert fidelity and reduce false positives, the Checkmarx team has developed another enhanced component: a base preset . The base preset focuses on the highest priority vulnerability queries to provide high fidelity results with reduced noise. As a result, it reduces total findings by up to 70%. The base preset was designed to boost scanning efficiency, prioritizing the swift retrieval of results with pertinent and impactful vulnerabilities. The preset can also be used as a starting point and customized to meet your specific requirements. It is available regardless of which mode – fast or in-depth – you use. 

The newly released scanning engine is used to optimize the SAST scans that are being executed to reduce overall scan time. This scanning engine further reduces scan times by tuning query parameters. 

The new scanning engine provides results that will support developers in their fast-paced development lifecycle. Through development and testing we have been able to provide up to a 90% reduction in scan time. This time saved is valuable and provides results that have shown to be higher fidelity. 

The Bottom Line

Up until now, users have had to choose – speed or security. This often led to sprawl, with multiple tools being used throughout an organization to meet the need of teams’ varied goals. Now, they can have both all in a single package – one vendor to deal with, one tool to learn, full transparency between security and development, and the flexibility to adapt as needs change. Checkmarx is the only solution that offers both in a single package.

Providing an application security solution that focuses on flexibility and high-fidelity results is what we are striving for at Checkmarx. This new release will provide reduced scan times with high quality results so that all members of your team can be successful – from the developers to the CISOs.

We are thrilled to announce that we have been recognized as a Leader in The Forrester Wave: Static Application Security Testing, Q3 2023. We believe this is a testament to our commitment to continuing to provide innovative best-of-breed solutions to the world’s largest enterprises. 

You can see the full report here. 

According to Forrester’s report, “Checkmarx started as a SAST specialist vendor and has grown to offer pre-release testing portfolio. The new Checkmarx One cloud platform enhances the different scan types for a better together story.” This follows last quarter’s publication of The Forrester Wave: Software Composition Analysis, Q2 2023. According to that report, “Checkmarx’s execution is impressive; it’s brought all the products under one cloud platform while also enhancing SCA and launching software supply chain security. The new platform unlocks product synergies….” 

We believe that this reflects a critical market change and realization — point solutions are not enough. Enterprises need an AppSec partner that understands the challenges that they face. It’s no longer good enough to have just a strong SAST or SCA solution. Enterprises need an AppSec platform can do it all (SAST, SCA, supply chain security, API security, DAST, IaC security, and container security) and do it all well.  

Forrester evaluated eleven of the top SAST providers against 26 criteria, in three different categories: Current Offering, Strategy, and Market Presence.  

The report recommends that SAST customers should look for SAST solutions that: 

• Increase developer velocity. 
• Secure new and emerging technologies. 
• Automate the remediation process.   

“Customers see fast time to value with the Checkmarx One platform,” noted the report.  We are proud to be recognized for our innovation and fast time to value.   

So, who should use Checkmarx? According to the report, “Checkmarx is well suited for medium to large enterprises using emerging tech in their software development.”  

Checkmarx SAST received the highest possible score (5.0) in eleven criteria:    

• Incremental findings 
• Language and framework support
• Support for new development approaches 
• Rules and policy management (consisting of native and custom rules, policies, policy enforcement – all sub-criteria that Checkmarx received a score of 5.0) 
• IDE integration 
• Ticketing tool integration 
• Innovation 
• Roadmap 
• Revenue 

We recently launched a new Developer Experience site, showcasing how we increase developer velocity by prioritizing teams on business impact, meeting developers where they live, and equipping developers with the tools and knowledge they need. 

The Forrester Report reflects what we currently have, but there’s more to come! Join our Checkmarx One 3.0 Enterprise AppSec Platform Launch event, where we will showcase even more of the innovative technologies that we have recently launched and showcase what’s to come across our entire enterprise application security platform. 

After a CVE on open source software has been discovered and a fix has been released, a fruitful practice for security researchers is to go deep into the nature of the CVE and the fix. 

In addition to curiosity, this good practice helps professionals and researchers extend their knowledge and improve their understanding of security vulnerabilities. 

Being an engineer at Checkmarx, the main tool that comes to mind to deep dive into the nature of vulnerabilities is the Checkmarx Static Application Security Testing (SAST) engine. 

This blog post will go into details about the nature of two separate vulnerabilities, CVE-2022-3602 and CVE-2022-3786, which hit the news at the beginning of November impacting a very well-known and largely adopted open source software package, OpenSSL. We will explore their fix and how Checkmarx solutions can detect such vulnerable code and support developers with remediation.  

CVE-2022-3602 and CVE-2022-3786 

The official page from OpenSSL, dealing with November’s CVEs (CVE-2022-3786 and CVE-2022-3602) can be found here. 

The two vulnerabilities affect OpenSSL up to version 3.0.6, and they involve a file named punycode.c, which is one of the files that manage the parsing of specific encoding of domain names (known as punycode). 

With both vulnerabilities, “A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking”, and they have been classified as CWE-120 by NIST, as a “Classical Buffer Overflow.” 

Buffer overflows

Generally, in C language, it is important to securely manage memory buffers to avoid any value written in a buffer from being reused elsewhere in the code and being interpreted with unexpected semantics. It’s worth noting that in C, buffers include strings too! 

Traditionally, strings are represented as a region of memory containing data terminated with a NULL character. Different string handling methods may rely on this NULL character to determine the length of the string. If a buffer that does not contain a NULL terminator is passed to one of these functions, the function will read past the end of the buffer or will lead to unexpected behaviors, such as buffer overflows. 

Let’s go through some technical details on the nature of the two OpenSSL vulnerabilities. 

CVE-2022-3602 

It is a buffer overflow related to the function ossl_punycode_decode, where there is a check on the size of a buffer for larger-than (>) values but omits the equals-to (=) values out of any check, as seen below. 

The red highlight is the old version of the ossl_punycode_decode source code (OpenSSL 3.0.6), while the green one is the fixed version (OpenSSL 3.0.7). 

The check at line 184 was leaving the case “=” unchecked, letting data with the same size of max_out variable to reach the next lines in the program and enter the further part of the function. 

The fix addresses such a case, by adding the “=” case to the ones that must be excluded with return 0. 

According to this evidence, the buffer overflow is due to the absence of a proper check against the size of a buffer which EQUALS the maximum, while there are cases defined to address sizes that are larger (return 0) and smaller (just continue). 

Technically, this case is similar to off-by-one vulnerabilities, where an application does not properly manage buffers which are exactly the size of the maximum expected, due to several assumptions on the data structures received in input. 

Various assumptions can be done on data structures received in input, and they all deal about trusting the source of such input, in term of its content, its format, and its size; to build secure code, assumptions should be avoided. 

Instead, sanitization and validation techniques should be implemented in the code: sanitization is the activity of removing extraneous data from a given input, transforming it into harmless data, compatible with business rules and security policies (e.g. removing special characters from a string before using it as a parameter in SQL); validation, on the other hand, is the activity of checking the content of a given input and rejecting any input that does not comply with application’s constraints (e.g. rejecting any string that is greater or equals to the size of a memory buffer). 

Checkmarx’s Codebashing training platform offers several lessons to teach developers how to write secure code in C, addressing proper methods to manage structures such as buffers, stacks, and heaps, which can help developers avoid introducing vulnerabilities in their code, such as CVE-2022-3602. 

For example, regarding off-by-one, Checkmarx’s gamified platform shows the student a part of vulnerable code and its side effects at runtime, both in memory and interactively: 

In this scenario, the vulnerable code is robust when the buffer is larger or smaller than the expected size; however, it is not safe when exactly 8 characters are entered. 

CVE-2022-3786 

t is a buffer overflow related to the function ossl_punycode_decode, which manages several cases of writing characters (chars) to a buffer, before using that buffer in further contexts, such as reading it as a string. 

OpenSSL 3.0.7 introduced the use of this PUSHC macro, to manage operations in buffers properly, as stacks: 

The macro is then used in place of old 3.0.6 “memcpy” functions, everywhere it is needed. 

Similar to the previous example above, the red highlight is the old version of the ossl_punycode_decode source code (OpenSSL 3.0.6), while the green one is the fixed version (OpenSSL 3.0.7). 

The change on line 301 manages the absence of the NULL character, which may lead to unexpected behaviors if the just populated stack is used in other contexts (e.g., as a string!). 

Checkmarx SAST has a specific query for C/C++ Language which is called “Improper_Null_Termination.” It is in the category of Buffer Overflows, and it has High severity. 

Its goal is to identify buffers that have not been properly terminated by NULL characters. 

By scanning OpenSSL 3.0.6 with Checkmarx SAST, the punycode file appears in two results related to line 276 and 297 for Improper Null Termination query: 

The description of the finding at line 276 states: 

“The buffer outptr in openssl-openssl-3.0.6cryptopunycode.c at line 276 does not have a null terminator. Any subsequent operations on this buffer that treat it as a null-terminated string will result in unexpected or dangerous behavior.” 

By scanning OpenSSL 3.0.7 with the same preset, the two vulnerabilities appear as fixed: 

Conclusion

Any application may present vulnerabilities due to the large size of applications, inheritances from older versions, mistakes, or errors. As evident with the recently identified OpenSSL vulnerabilities, even well-maintained and mature applications may present vulnerabilities that could be all but impossible to be identified by a manual review of the code. 

At the same time, the security awareness of developers is a key factor to produce and maintain secure code. 

Checkmarx SAST and Checkmarx Codebashing can help in raising the bar of security in your company and in your developers and security champions. Both solutions are fully integrated into our Checkmarx One Application Security Platform. 

Learn More

To learn more or see for yourself, request a demo today! 

But modern applications also present some steep challenges, not least in the realm of security. In order to thrive in the modern development landscape, developers and AppSec pros alike must be sure that their security skills can address the variety of threats that teams face today – a time when cyberattacks are growing steadily in frequency and scope.

Here’s a list of four essential security skills that anyone involved in modern application development should possess.

IaC Security

Infrastructure-as-Code (or IaC) tools have become an essential part of many modern application development workflows. Using IaC, teams can automatically provision large-scale software environments, which maximizes scalability and minimizes the risk of configuration mistakes due to human error.

But the downside of IaC is that, if the configurations applied using IaC templates contain security issues, those issues will be proliferated across your entire environment. And in most cases, the IaC tools themselves do nothing to alert you to potential security issues.

That’s why developers and AppSec teams must learn to follow security best practices when configuring IaC templates, such as:

• Secure your secrets: Don’t hard-code passwords or other secrets into IaC templates. Store them in an external secrets manager instead.
• Modularity: Keep IaC templates short and modular. Trying to cram too much configuration into a single template increases the risk of making a mistake.
• Use default settings with care: Don’t blindly trust default IaC settings. Make sure you tailor templates to your environment.

Just as important, teams should use IaC scanning tools to validate their IaC configurations prior to applying them. IaC scanners automatically check IaC templates for misconfigurations that could create security issues.

Open Source Security Risks

There are many excellent reasons for modern development teams to leverage third-party open source code. Open source saves time because it allows you to reuse code that someone already wrote rather than having to write it yourself from scratch. It is also often easy to customize. And it’s usually free of cost, which is never a bad thing.

Yet open source also poses some significant security risks when you incorporate it into your applications. You can’t guarantee that third-party open source developers adhere to the same security standards that you do when they write their code.

For that reason, it’s critical to know where in your application you incorporate open source code, and also to scan that code to identify known vulnerabilities within it.

Container Security

Modern applications are often deployed using containers. Because containers – and the orchestration platforms used to manage them (like Kubernetes) – add another layer of infrastructure and complexity to your software stack, they create a variety of potential security risks that would not be present if you were deploying applications directly on a host OS, without having a container runtime and orchestrator in the equation.

Modern developers and AppSec teams need to know what these risks are and take steps to address them. A full discussion of container security is beyond the scope of this article, but basic concepts include:

• Image security: Securing container images by ensuring that any external components on which they depend are secure, as well as using a container image scanner to check for vulnerabilities.
• Configuration security: Scanning the configuration files that are used to deploy and orchestrate containers. Like IaC templates, these files can contain configuration mistakes that enable security breaches.
• Runtime security monitoring: Using monitoring tools that can collect and analyze data from across complex containerized environments (which means collecting data from various containers, from all of the operating systems running within the cluster of servers that hosts your containers, and from the orchestration platform) to detect signs of breaches at runtime.

Microservices Security Risks

Microservices have become massively popular because they make it easy to build agile, scalable applications that lack a single point of failure, among other benefits.

But microservices also significantly increase the complexity of application architectures, which in turn increases the risks of security issues. Because microservices rely on the network to communicate with each other, there is a higher risk of sensitive data exposure. Insecure authentication and authorization controls between microservices could enable a breach to spread from one microservice to an entire app. Security problems with the tools used to help manage microservices (like service meshes) create another set of security risks to manage.

As with container security (which, by the way, is a closely related topic, because microservices are often deployed using containers), there is more to say about microservices security than we can fit into this article. But some core microservices security best practices for developers and AppSec teams to follow include:

• Microservices isolation: When designing your microservices architecture, strive to isolate each microservice as much as possible. Allow interactions between services only where strictly necessary.
• Authentication and authorization: Always require authentication and authorization for microservices to communicate with each other.
• Network isolation: Isolate the internal networks that microservices use from the public Internet, and never expose a microservice directly to the Internet unless it needs to be.

Conclusion: Modern Application Development Requires Modern Application Security

Most of the security challenges discussed above simply didn’t exist ten years ago. Back then, no one was provisioning hundreds of servers using IaC templates or deploying applications with highly complex architectures based on microservices and containers.

But those practices are the norm for modern application development. Developers and AppSec teams must respond by ensuring that they are able to leverage the tools and skills necessary to meet the modern security risks that go hand-in-hand with modern application development.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Click here to learn more about security in the context of Modern Application Development