DevOps

DevSecOps: What DevOps NEEDS to Be When It Grows Up

Jonathan Singer — Tue, 08 Oct 2024 07:48:32 +0000

DevOps Security: Where Are We Now?

DevOps represents the fundamental cultural shift in software engineering towards performance: high performing teams, and high performance code.

In DevOps, security was never a primary consideration.

DevSecOps represents the reality that DevOps must grow to encompass security. Eventually, performant code will mean secure code by default – but we’re not there yet. How do we get there?

Let’s start with where we are now. Earlier this year, Checkmarx ran a survey asking CISOs about their current AppSec programs. One of our questions specifically asked: “Where are you on your DevSecOps journey?” You can see the answers below:

On the surface, this doesn’t look too bad… until you consider the details. Based on our scaling, “medium” only represents the “definition and strategy” phase. The actual process of integration and automation is where companies actually start “doing” DevSecOps, and only 1 in 5 companies surveyed have reached that stage in some form.

And let’s be clear – integration and automation are the goals of DevSecOps. DevSecOps is about taking the needs and outcomes of application security and integrating them with the processes and culture of DevOps. In 10 years, there should be no difference between “DevOps” and “DevSecOps.” DevSecOps is just what DevOps needs to be when it grows up.

DevSecOps: The Path to Maturity

OK – how do we get there? If I were to create a rough sketch of DevSecOps maturity, it would look like this:

Let’s start on the bottom. This is traditionally where AppSec finds vulnerabilities, and essentially throws them over the wall to developers and says “here, fix these.” I have some bad news for you, this is actually “Shift Left” in action. Maybe that’s flippant and a bit unfair; but it is the base level of maturity that puts organizations on the road to DevSecOps.

The next level focuses on the developer experience. Here, AppSec teams and developers alike realize that “Shift Left” isn’t really working. Not because anyone is bad, uncaring, or unintelligent, but because it is only intended to be the first step. In that stage, AppSec got tools to find and triage vulnerabilities. Now developers need tools to manage those vulnerabilities themselves without breaking their workflow. The “developer experience” stage of maturity focuses on IDE-integrations, remediation guidance, and other ways to keep developers focused without greatly disrupting their flow.

But like “Shift Left”, focusing on the developer experience eventually hits diminishing returns. Organizations will get stuck, and then they will need to begin to move towards the third step of maturity. This is where you take the foundational understandings of the first two steps, and work to define a DevSecOps culture.

DevSecOps: Worth the Effort

Culture is hard to change, but luckily, DevOps people have done it before. If you go back to the early days of Agile and Scrum, teams would hold daily standups, and then go back to working exactly the way

they had before. But, as modern DevOps organizations can confirm, it’s worth the effort. For DevSecOps, it’s also worth the effort. Here is an example of a Checkmarx customer’s journey, and you can see them go through the stages and the results:

This is a chart showing the number of vulnerabilities remediated by a Fortune 100 company, and it’s a powerful representation of what things look like when teams integrate.

If you’re curious about the types of things this customer did to get from the left to right side of the graph above, here we’ve got some examples ready based on where you are from a maturity standpoint:

Shift Left: If you just need to get something in place to start getting vulnerabilities over to developers, the easiest way is to integrate your AppSec tools with your feedback tool (be careful here, you don’t want to suddenly shunt 10,000 JIRA tickets over to the devs, so set some policies around it). Click here to see a video showing how easy that the integration is to do with Checkmarx.

Developer Experience: The easiest way to start improving your developer experience is by integrating with their IDE of choice. This is also simple to do with Checkmarx, and here is a video showing how: Watch Now!

DevSecOps: We’ll explore the keys to DevSecOps in detail in the next blog, particularly culture, automation, and speed, but we mentioned the importance of policy management in our first bullet point. While designing policy is difficult – it relies on great communication between development teams and security teams – creating and implementing policy with Checkmarx is easy. Here’s a video showing how it’s done: Watch Now!

This blog is just our first in a series on DevSecOps. Our next blog will focus on how to change culture, the need for automation, and the true meaning of “speed” within the context of DevSecOps. In the meantime, the videos I just listed are only some a few of those you can check out over on YouTube showing how easy it is for platform engineers and developers to integrate and work with Checkmarx One. Check them out here!

SBOM and the Bill that is Coming

John Allison — Thu, 25 Apr 2024 17:27:46 +0000

No one likes paying bills, or at least I don’t. However, what is absolutely worse is finding yourself with an unexpected bill that is coming due. For software developers, there is a big bill coming due in the terms of a Software-Bill-of-Materials (SBOM). While there has been some debate if governments, including the US, would formally mandate SBOMs or let industry self-regulate, this debate is now over. Governments around the world are exploring how to mandate SBOMs for software either sold to the government or sold in a specific market. This post is going to focus on the upcoming bill due to the US federal government, since this is the most near-term bill coming due.

The US government’s Cybersecurity & Infrastructure Security Agency (CISA) and National Security Agency (NSA) summed up the value of an SBOM in their recent publication “Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption”.

SBOMs provide improved visibility into the pedigree of the software that the customer organization is evaluating, deploying, and/or operating within their environment. This increased visibility into all software is critical for proper supply chain risk management and overall enterprise risk management. SBOM content provided to and consumed by customers informs risk management for customer organizations without impacting sensitive intellectual property interests of software suppliers. Even before the SBOM data is consumed by the customer, the customer benefits from the supplier having the SBOM data and the potential to use it to inform risk decisions. This does not guarantee that the supplier will use this data, but having the data is a necessary first step.

If a supplier does not have visibility into their software supply chains, customers should be cautious of the trust placed on that software and its supply chain. While there may not be any currently known active exploits or vulnerabilities, such a supplier may not be in a position to make any claims or assurances. A supplier that provides an SBOM signals its visibility, and the quality of this visibility, into its supply chains.

The Executive Branch has issued multiple cybersecurity guidance documents over the past couple of years – from the National Cybersecurity Strategy, to different Office of Management and Budget (OMB) Memorandums, and to a variety of agency specific planning documents. One of the common threads throughout nearly all this guidance is that software producers should be held to a higher standard when it comes to producing secure software, and that the SBOM is the key deliverable to ensure that happens.

We can (and I do often) debate the actual value of an SBOM within the broader picture of application security as a measure of risk, but that debate is unlikely to persuade the US Government from mandating SBOMs from software vendors. SBOM can be a valuable tool for risk reduction but, in itself is insufficient. In my opinion, it is more important how you use the insight provided by the SBOM to manage risk, than collecting an SBOM itself.

So, what is happening?

Some highlights from what I know as of today:

The Department of Homeland Security will be mandating SBOMs within all existing and future contracts.
The Army is formally asking industry on how best it can mandate SBOMs.
DHS and the Cybersecurity Infrastructure Security Agency (CISA) has started the process of requiring contractors to attest that all software produced was done in accordance with NIST 800-218, which includes SBOMs (sort of).
The Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA) has proposed updates to Federal Acquisition Regulation to include mandating the delivery of SBOMs.
The Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued public guidance on how customers of SBOMs can effectively consume SBOMs, and why they should require them from their software vendors.

I suspect this is just the tip of the iceberg given that OMB literally is directing federal agencies to adopt SBOMs through M-22-18. This is no longer a question of if, but rather of when, and how.

I spent 24 years in the Air Force, primarily within the complex DoD acquisition process. I’m going to get out my acquisition crystal ball and forecast how I think this will play out over the next year or so. I think there will be some significant challenges for the US Government to achieve the value they desire from SBOMs, and I will discuss what challenges I think they will have.

All Proposals Will Require SBOMs

We are seeing this trend start already, just search SAM.GOV for SBOM. I expect all Request for Proposals to require the vendor to submit SBOMs. The submission will be mandatory and failure to submit the SBOM is likely to result in being non-compliant and excluded from the award.

The easy contracting approach is to just require the SBOM within the proposal, and the box is checked. I think this approach will be used for a vast majority of acquisitions. I think we will see a subset of the acquisitions that incorporate the SBOM within the technical evaluation process. Once this approach happens, the complications start.

To effectively incorporate the SBOM into the technical evaluation process, the Government is going to be challenged in a) ensuring that the SBOM is comprehensive, b) dealing with what may be false positives, and c) how do you assess it in a protest resistant manner. While this could be a valuable tool in the technical assessment, this will lead to several successful protests before the Government develops protest proof processes to incorporate SBOMs into the technical evaluation.

All Contracts will Require SBOM as a Deliverable

I expect every contract to include an SBOM as a deliverable. I think that this will be the minimum. This doesn’t mean that anyone will look at or use the SBOM for anything. For many, it will be a checkbox to meet agency guidance. Overtime and with software or cybersecurity specific acquisition programs, I think we’ll see the contracts to go beyond just requiring a deliverable.

We see this already in the draft language for the DHS, which requires delivery of an SBOM that certifies that all software delivered to be free from all known vulnerabilities. This is an unrealistic requirement and that opens the discussion on what to do with the vulnerabilities included in the SBOM. Even the DHS understands this, since they continue in their draft language to require the vendor to provide a plan to remediate all the vulnerabilities identified in the SBOM.

As a minimum, I expect all contracts to require an SBOM to be delivered. For software and cybersecurity focused programs I expect:

Either monthly or quarterly deliveries of an SBOM
SBOMs being delivered with each software release
Companies having to provide and maintain a remediation plan – this may be called a Plan of Actions & Milestone (POA&M), a Risk Register, or something new

Security will have Consequences

I see a lot of opportunity to use SBOM’s to influence vendor behavior. I expect that there will be a few attempts at this in the short-term, but we are unlikely to see this broadly adopted until sometime in the future. It will take some time to build up the skill and government resources to do this effectively, and to do so in a manner that a) avoids outright conflict with the vendor, and b) doesn’t drive away the vendors you are interested in from the acquisition to start with.

My experience leads me to two conclusions about incentives: a) the Government is more comfortable doing negative incentives, and b) positive incentives are more effective than negative incentives. So, I’m going to skip the negative incentives and focus on positive incentives.

While Fixed Price Contracts have been all the rage for recent development efforts, I think those days may be numbered. I think SBOMs, and more importantly the vulnerability data can easily be incorporated in both award fee and incentive fee determinations. So, for cost plus contracts, I think the vendor’s profits will get tied to the deliverable of software with objectionably measurable minimum number of vulnerabilities.

My favorite approach here would be the use of a Cost Plus Incentive Fee (CPIF) contract, where the incitive fee is based on the measured security risk posture of the software being delivered. The higher the security posture, the higher the incentive fee is to the contractor. Using third party tools like Checkmarx One, would allow the contractor to know objectively before the software release is submitted to the Government of the measured security posture. The same tooling would be used by the Government to generate the incentive fee. This is important since there needs to be agreement on how the incentive fee will be calculated to be effective, and the contractor must have a good understanding of their score in time to change their behavior. As a cloud native solution, the Government could provide the contractors Checkmarx One accounts as Government Furnished Information/Equipment (GFI/GFE) which can effectively negate the contractor’s argument on how different their internal tooling is compared to the Governments measurements.

I like CPIF because they are supposed to be more objectively measurable and with tools like Checkmarx One, fairly simple and straightforward to implement. This approach can also work with Cost Plus Award Fee (CPAF) contracts as part of the award fee determination process. Award Fees are notoriously subjective, so it may be more of a challenge for a contractor to characterize the return on any investments in improved application security to their profit. Award Fees are a powerful tool for incentives if used properly, and can use objective inputs such as application security risk scores, as well as subjective observations.

Whether the incentive is based on CPIF or CPAF, the reality is that application security will have consequences. Specifically, application security will directly impact the developer’s profit, as it should. The beauty of using a tool like Checkmarx One is that both the developer and the Government will have the same application security picture, and the developer can make an informed decision on the prioritization of application security knowing the potential impact to contract compliance and profitability.

Next Steps

It really doesn’t matter what kind of software you develop; you would be wise to ensure that you have the ability to generate an SBOM. While the US Government is working on mandating SBOMs for software delivered to the Government, the European Union’s draft Cybersecurity Resiliency Act (CRA) is likely to mandate SBOMs for all software sold commercially within the EU. At some point once SBOMs are in place within the US Government, large enterprise customers will be expecting the same. Don’t fight it, figure it out and build out the capability. This includes working with your entire supply chain to ensure you have a complete accountability of the software within your product. But please don’t build SBOMs for SBOM sake. Use SBOMs as a tool to identify and prioritize risks and take action to reduce the risk posture of your product.

Application security is here to stay and SBOMs are an inherent part of application security. I’m excited to be in Checkmarx, where we are leading in the building of tools that help developers meet the upcoming US Government requirements. My passion is to enable innovative companies to sell to the US Government, but you can’t sell if you can’t produce an SBOM. If you’d like to learn more about Checkmarx, and how Checkmarx One can get your company prepared for the upcoming SBOM requirements, please reach out to us. We’d be happy to help you be successful in all thing’s application security, including SBOMs.

Building #DevSecTrust with JetBrains and Checkmarx

Michael Smythe — Mon, 22 Apr 2024 11:00:00 +0000

In the world of application development, success relies on developers being able to use their preferred tools to deliver innovative, secure products. Getting the developer experience right is a mission that unites Checkmarx and JetBrains, a global software vendor that creates professional software development tools and advanced collaboration solutions. See this in action by watching our latest joint webinar.

We are pleased to announce that we are building on our long-standing partnership and earlier integrations with JetBrains’ flagship, IntelliJ IDEA. This will deliver the full power of the Checkmarx One Application Security Platform into key JetBrains tools. Individual developers and teams will be able to boost their security performance while continuing to deliver applications at speed.

Partnering for Secure Code Productivity

In 2022, Checkmarx and JetBrains first partnered by bringing Checkmarx SCA capabilities natively into IntelliJ IDEA Ultimate through the Package Checker. Using the pre-installed Packager Checker plugin, five million developers can use IntelliJ IDEA to initiate Checkmarx SCA scans directly from their development environment. This can be done for free, without the need to become a Checkmarx customer, with detailed results showing OSS vulnerabilities as soon as the scan is complete. Frictionless integration, with modern application development workflows, makes it easier to secure applications before they are compiled, instead of waiting for deployment to identify vulnerabilities.

Building on this initial launch, the Checkmarx SCA plugin is also available for a wide range of JetBrains developer tools including WebStorm, PyCharm, Rider, ReSharper, Qodana, and GoLand.

Building #DevSecTrust

The next phase of our partnership with JetBrains is now live. Checkmarx customers can now bring the full functionality of the Checkmarx One 3.0 application security platform, including SAST, SCA, and IaC security, to IntelliJ IDEA through the Checkmarx One JetBrains Plugin.

We know that making security tools available to developers doesn’t automatically lead to more secure code. Fast, secure application development is the goal, but this is hard to achieve if security tools lack intuition and cause friction in developer workflows. To help developers, Checkmarx One doesn’t just provide detailed information on each vulnerability discovered, including remediation recommendations and examples. We also enable the developer to navigate with one click from the identified vulnerability directly to the best fix location in the source code, so no time is wasted.

Focusing on exploitable vulnerabilities is also critical to effective and efficient remediation. That’s why the newest releases of JetBrains’ IntelliJ IDEA, WebStorm, PyCharm, Rider, and ReSharper tools include Checkmarx’s Exploitable Path capabilities for Java, JavaScript, C#, and Python languages. This capability gives developers the ability to see whether there’s a path from the project code into the vulnerable package code through which the vulnerable packages could be exploited. Developer teams can focus on the remediation of actively exploitable vulnerabilities first so their time is spent on the most critical areas.

Our #DevSecTrust approach can also be seen in reducing the number of irrelevant alerts. Checkmarx starts work before it is integrated into the IDE. It can be finely tuned by AppSec teams to ensure the accuracy of scans and effective prioritization of findings. Noise is reduced before it enters the workflow, so developers can be confident that the vulnerabilities they are being alerted to are genuine and they know what needs to be prioritized for fixing. This ultimately helps CISOs drive strategic initiatives to uplevel application security posture.

Collaborative Development with Security in Mind

Checkmarx One 3.0 can also be integrated into TeamCity, a powerful CI/CD tool for DevOps teams of any scale, developed by JetBrains. This means organizations can normalize the inclusion of security scanning in team application development projects.

The Checkmarx One TeamCity plugin enables users to trigger SAST, SCA, IaC Security, and API Security scans directly from a TeamCity project. It provides a wrapper around the Checkmarx One CLI Tool which creates a zip archive from a source code repository and uploads it to Checkmarx One for scanning. This plugin provides easy integration with TeamCity while enabling scan customization using the full functionality and flexibility of the Command Line Interface (CLI) tool.

Key features of the TeamCity plugin include:

Automatically triggering CxSAST, CxSCA, IaC Security, and API Security scans from TeamCity projects.
Use of CLI arguments to customize scan configuration.
Automatic updates to the latest plugin version.
Interface for viewing scan results summary and trends in the TeamCity environment.
Direct links from within TeamCity to detailed Checkmarx One scan results and reports.
Generating SBOM reports.

This helps teams enhance software security, governance, and reporting.

A Powerful Partnership

JetBrains and Checkmarx are recognized leaders in their fields, and this long-term partnership unites us in delivering a game-changing developer experience, raising the profile of AppSec without compromising productivity or workflows. This empowers CISOs to elevate code security and deliver more secure apps, faster.

Getting Started

It couldn’t be easier to get started with Checkmarx in JetBrains tools. Our dependency checker plugin is already a native part of all JetBrains IDEs, so developers can access advanced SCA right now.

The Checkmarx One 3.0 plugin can be easily installed by Checkmarx customers into the IntelliJ IDEA development environment from the Checkmarx marketplace. It is also available as an on-premises solution. Similarly, the TeamCity plugin can be installed for customers with a Checkmarx account and is also available on-premises if required.For more information, contact the Checkmarx Team or watch our latest joint webinar today.

Transforming Security + DevOps into DevSecOps

Rebecca Spiegel — Thu, 04 Nov 2021 12:15:48 +0000

Over the last couple of years, DevSecOps has become the latest buzzword. The idea behind the concept is that it makes everyone accountable for security, and to implement security decisions and actions at the same scale and speed as DevOps.

Organizations with a DevOps framework should be looking at how they can shift towards a DevSecOps mindset, bringing individuals across all technology disciplines to a higher level of security proficiency. The goal is to ensure security is built-in to application development rather than bolted on afterward. However, there is often a perception that adding security testing into the mix will negatively impact DevOps speed. But by deploying AppSec tools that integrate security with every stage of the SDLC, businesses can reduce the cost of compliance and deliver secure software faster.

So how can organizations go about making this shift and identifying the technical tools to support it? The first step is to determine where they sit on the DevSecOps maturity scale because despite the generally accepted definition of DevSecOps, in practice, it is a concept that means different things to different organizations based on their software development and security maturity. We typically see four levels:

Level One: Checking the Box

Organizations often have the mindset to focus mainly on meeting compliance requirements. However, simply answering yes or no questions in a security audit doesn’t necessarily make the business any more secure. Therefore, organizations should aim to mature onto other levels.

This level of DevSecOps maturity is typical of companies that wait to perform security assessments until just before deployment when there’s often no time or budget remaining at this point to address high-risk vulnerabilities adequately. These tests may or may not include automated vulnerability scanning. The high-risk vulnerabilities will often be documented in the development’s team issue tracker, which may not allow for complete organizational visibility. As a result, vulnerabilities may be silently available for exploitation with no clear plan for remediation.

Level Two: Situational Security Awareness

The next level of maturity sees organizations start to gain more situational awareness. They begin to identify the risks living inside their applications, not about fixing code but understanding the risks. So, rather than scanning for compliance, they know that there are risks worth addressing within applications.

Teams may identify vulnerabilities through manual testing, code reviews, or even automated vulnerability scanning and then deep dive into to assess risk with greater accuracy based on proven or perceived exploitability. The organization will typically document these high-risk issues and implement a compensating control as a permitted policy exception with a future deadline for proper remediation.

These quasi-effective compensating controls may help organizations make software changes, but those changes would properly remediate the discovered risks. Instead, the stakeholders and development team involved in the original release may be completely different as future deadlines approach. As a result, historical vulnerability documentation sits there without a clear path for resolution.

Level Three: Remediate Everything

If organizations tried to remediate every vulnerability, they would experience a massive slowdown in DevOps. This slowdown results from the heavy lift of combing through historical code and perhaps not using AppSec solutions that help developers prioritize fixes.

Instead, organizations typically develop an understanding of how to manage that risk by designing processes to support policies that match their compliance requirements and risk appetite. F For example, many organizations have the approach to remediate high-severity and OWASP Top 10 vulnerabilities within a specified timeframe.

A higher security posture or fallout from a recently exploited vulnerability may lead to procuring new automated vulnerability scanning tools. Lack of engineering in integrating these tools into developers’ existing tools leads to a complete re-tooling of the organization’s software development practices. Along with the new tools, a higher level of scrutiny on detected results may lead non-technical managers to impose strict policies for deploying detected vulnerabilities that may be incompatible with business goals and, at times, technically infeasible to enforce.

Managers may incorrectly interpret the slowdown as developers being unwilling to adopt new tools and practices. The reality is that slowness may be due to a combination of several factors:

A subset of the organization’s developers may need the training to understand secure coding concepts, including how vulnerabilities manifest and are exploited.
Developers are having difficulty in locating and consuming vulnerability results out-of-band of their existing development tools and workflows.
Developers being overwhelmed with the frequency of reviewing vulnerability data produced from automated scanning tools when scans frequency is not tied appropriately to the development process.

Level Four: The Holy Grail of AppSec

At the highest level of code security maturity, organizations focus on preventing the introduction of new vulnerabilities and effectively managing technical debt by integrating continuous AppSec testing without stopping or slowing new development. Training developers to write secure code and remediate vulnerabilities and procuring developer-centric solutions helps further accelerate DevSecOps. Plus, if solutions support the developer with fine-tuned results and features like best-fix-location, remediation suggestions, and multi-scan engine results correlation, they’re further supported in making fixes faster.

A higher security posture or fallout from a recently exploited vulnerability may lead to procuring new automated vulnerability scanning tools. Management understands that any attempt to “boil the ocean” by stopping all work while identifying, accurately assessing, and fixing all high-priority vulnerabilities is not infeasible. Instead, they:

Identify the highest-profile applications and focus on identifying high-risk vulnerabilities in those applications.
Focus application security training on teams that maintain these high-profile applications.
Scale the training effectiveness by involving AppSec experts in the development teams’ vulnerability triage and remediation efforts.
Engineer the integration of vulnerability result consumption into the developers’ tools and workflows.

How to Develop Your Organization’s AppSec Maturity

While seemingly simple in principle, how do teams move through the various maturity levels without being overwhelmed by thousands of new alerts while optimizing their AppSec program and tools? There is no one-size-fits-all approach, but here are some practical best practices our Professional Services teams have seen or put into practice.

Some organizations run baseline scans on their existing applications and put findings into technical debt backlogs, which they gradually reduce over time. Other organizations set a policy that any new releases won’t introduce new vulnerabilities, ensuring compliance with automated AppSec testing kicking off directly from their DevOps environments. Checkmarx’s Application Security Platform and AppSec Maturity Services help both DevOps and AppSec teams understand and assess where they are today and what they need to do to mature their environment.

Adoption Requires Top-Down Support and Bottom-Up Enablement

Most importantly, DevSecOps needs top-down executive directives, otherwise prioritizing AppSec won’t get buy-in from the wider team. Senior management support and exemplary technical leadership are critical because changing an existing DevOps approach to integrate security includes a degree of disruption as teams adjust to the new process. Managers might purchase AppSec tools, but individuals will have differing levels of experience in implementing and using them. While developers interested in security may embrace the new process, others will be reticent about what they see as an unhelpful change in their preferred methodology. Consequently, adoption is patchy, and the tools don’t deliver ROI. Even though developers want to write secure code, their priority is to ship feature sets and functionality quickly. Hence, leadership needs to support the technical adoption of tools through procuring developer-centric products and proper training.

Where does your organization land? In level one, two, three, or four?

Download Our Ultimate Guide to SCA Here

On the Road to DevSecOps: Top Three Benefits of CxFlow

Stephen Gates — Thu, 16 Jul 2020 07:40:41 +0000

Most organizations who are in the process of transitioning to DevOps understand that this new software development methodology is really about a change of corporate mindset, improvements to internal practices, and the usage of development tools that increase an organization’s ability to deliver software at higher rates. DevOps enables organizations to provide timely software solutions to their customers and compete more effectively in the market in which they operate.

Pertaining to development tools, DevOps is also about automation of the different tooling in use that improves the speed of software delivery. Designed primarily for those embarking on DevSecOps initiatives, Checkmarx CxFlow integrates security into the existing tools so that secure software development can be achieved without requiring any extra tools. Using the existing tools already in place, CxFlow seamlessly operates in the background.

Checkmarx CxFlow is all about the automation of AST solutions into the tooling within today’s organizations. It was developed to address AST automation head-on, but there is more to CxFlow than meets the eye. Below is a list of the top three benefits organizations will experience when using CxFlow with their CxSAST and CxSCA deployments. Let’s delve a little deeper into what CxFlow is all about.

#1 The Most Shift-left Where Automation Can Occur

Traditionally, application security testing (AST) solutions on the market operate within the CI tooling in use and scans are normally performed after a merge/build has taken place – further to the right of the SDLC, so to speak. CxFlow on the other hand, allows organizations to shift that functionality to the left since CxFlow is an orchestration layer that simplifies the implementation and automation of AST in today’s modern development environments.
Using CI plugins to launch AST scans are still supported and even recommended, for example, launching scans from Jenkins, CircleCI, Travis CI, Bamboo, TeamCity, etc.

However, AST scans can now be integrated and launched directly from code management tools as well. CxFlow effortlessly integrates with application release orchestration and agile planning tools such as GitHub, GitLab, BitBucket, Azure DevOps, etc., enabling fully automated scanning of applications and the delivery of consumable results to the developers themselves.

Plus, CxFlow integrates directly with bug/defect tracking tools like Jira, Rally Software, ServiceNow, SonarQube, etc. This eliminates the need for time-consuming manual scan configurations and allows developers to publish and update findings based on policy to a defect/backlog management system for application teams to track.

#2 End-to-End Automation, from Scanning to Ticketing

Leveraging Checkmarx’s unique ability to scan uncompiled code, CxFlow automates the steps required to scan code earlier in the SDLC. This eliminates the need for time-consuming manual configuration of scans and allows developers to publish and update scan findings based on a pre-configured policy within the code management tools themselves. After the initial configuration, AST scan activity is performed hands-off with no human intervention required whatsoever beyond a pull request initiated by a developer.
With CxFlow, upon a pull request in the code management tools in use, the developer not only receives notifications from scans as comments that are related to functionality, but also as comments that are related to security, since CxFlow easily integrates with IDEs and code management tools in use. Just like that, the developer is able to have their code reviewed once for all bugs and would be able to close the full feedback loop with ticketing systems, all while the code is still fresh in their mind. This allows developers to:

Catch and fix vulnerabilities during the coding phase (earliest stage of development).
Work as usual with no disruptions, no new tools, no additional security reviews needed, etc.
Treat security bugs and functional bugs alike and allows them to immediately address those bugs within the code branch(es) they’re currently working on.
Reduce the overhead of manually opening, validating, and closing security tickets without spending countless hours in bug tracking/ticketing management systems.

#3 Removes Friction Between Developers and DevOps/AppSec Teams

CxFlow eliminates the manual and time-consuming configuration per project within DevOps, thereby removing the friction between developers and DevOps teams when needing to add scanning steps into the jobs of all CI pipelines, since adding jobs/steps to scan code is challenging using the older CI-scan model. Today, CxFlow:

Simplifies the AST lifecycle through automation into the tools already in use by taking a web listener approach, listening for events from the source code repositories and triggering AST scan actions upon such an event.
Enables developers to have little if any intimate knowledge of CxSAST or CxSCA solutions since developers receive their automated scan reviews as comments/reports right from the repositories, not the AST solutions deployed.
Works off the concept of a protected-branching strategy whereby you can configure master, develop, and security branches, for example, that are all deemed protected. This means that pull requests, push events, etc. will trigger scans and produce results when any code changes are made that are associated with those protected branches.
Reduces TCO and improves ROI for scanning tools by reducing the need to manage and maintain multiple CI plugins concerning installation, updates, etc., when multiple CI solutions are in use.

Conclusion

CxFlow streamlines the configuration and orchestration between the development tool set and the Checkmarx Software Security Platform to drive AST automation. With this, organizations can instantly onboard their development, security, and operations teams and simplify the governance of their security policies and DevSecOps processes.

The traditional AST solution providers are leaving developers behind, because without the ability to scan source code directly, the traditional players can’t efficiently work within code management tools similar to Checkmarx.

Clearly, integration is key to automation and CxFlow enables the most shift left approach where automation can actually occur within the SDLC—changing the way AST solutions are integrated with in all DevOps environments.

Mutation Cross-Site Scripting (mXSS) Vulnerabilities Discovered in Mozilla-Bleach

Yaniv Nizry — Wed, 08 Jul 2020 11:11:49 +0000

As part of the beta testing phase that took place earlier this year for our recently launched Software Composition Analysis solution, CxSCA, the Checkmarx Security Research Team investigated Mozilla-Bleach, finding multiple concerning security vulnerabilities. Patches were released in mid-March 2020, with Checkmarx CxSCA customers using Bleach receiving notice of the issues in advance. Given that the patches have been in-market for some time, giving Bleach users sufficient time to update their software versions, we’re now publishing the full technical report and proof-of-concept video for educational purposes.

Overview

According to documentation, “Bleach is an allowed-list-based HTML sanitizing library that escapes or strips markup and attributes and is intended for sanitizing text from untrusted sources.” In simpler terms, Bleach is a very user-friendly HTML sanitizer, and its main purpose is to disallow arbitrary tags to run (e.g., JavaScript (JS) tags and attributes to prevent cross-site scripting (XSS)).
After a bit of fuzzing and using some different approaches, Checkmarx researchers discovered the possibility that a mutation XSS (mXSS) vulnerability may exist. With further digging, these suspicions were confirmed, and several mXSS vulnerabilities were discovered in the Mozilla-Bleach python package.
An attacker abusing these vulnerabilities would have the ability to execute an arbitrary JavaScript code on the user end, via various sites or projects that use Bleach.

Mutation XSS (mXSS)

A mXSS vulnerability occurs when there is incoherent parsing between the client and the sanitizer. To understand this better, the following example should help.
Let’s see how a standard browser interprets invalid HTML. When we enter the data below into the innerHTML of the page:The browser will modify the data to make it valid html. In this case, this is what the output looks like:
Now let’s try to change the div tag to a different type of tag, for example:

Doing so will generate the result below:

Both examples act differently because the data inside the tags are parsed differently according to the tag type. Now, imagine the parser goes from left to right. In the first case, after entering the div tag, the parser stays as html and opens an a tag with the title attribute (because the “closing” div tag is text in an attribute, it will not close the tag).
In the second case, when the parser enters the style tag, it changes to CSS parser, which means no a tag is created, and the style tag will be closed where the attribute was supposed to be.
So, how can this information help us in finding vulnerabilities? Imagine a tag that parses differently in different cases, for example, the noscript tag. The trick here is that the noscript tag in HTML is treated differently, whether JavaScript (JS) is enabled or disabled. When JS is enabled, the data inside the tag is parsed as JS. But, when it’s disabled, the data is parsed as html. In nearly all cases, JS is enabled in browsers.
Let’s take a look at how the following input is being interpreted with, and without, JS enabled:

Here, JS is disabled:

Here, JS is enabled:

Vulnerability: CVE-2020-6802

When we tried to pass the above input to Bleach, it sanitized the ‘< ‘characters in the attribute, but also it closed the a tag! This means that it parsed the data in noscript as html.

In this case, the only thing left is to avoid this sanitization. If that wasn’t enough of a challenge, we attempted to enter another parsing into the equation.

This provided the outcome we were anticipating.
Sanitizer view:
Enters noscript and the parser is HTML, opens a style tag, and starts parsing as CSS (or raw text). Everything after the style tag isn’t parsed as html, so from the sanitizer’s viewpoint, there is no closing noscript tag nor img tag.
Browser view:
Enters noscript and the parser is changed to JavaScript. Now the “