Automating material code change detection for continuous compliance

Thank you to these industry experts for their contributions to this post: Fredrik (Freddie) Hult, CISO, Santander; Simon Devlin, Head of Product Security, Santander; Dov Katz, Managing Director, Distinguished Engineer, Morgan Stanley; Samir Sherif, CISO, Absolute Software; Charles Blauner, Operating Partner, Team8; David Fairman, CIO & CSO, Netskope; Tomer Gershoni, CSO, ZoomInfo; Clint Huffaker, Practice Manager – Application and API Security, World Wide Technology; and Shawn Asmus, Practice Director, Application Security, Optiv.

Change is a fundamental part of the growth and evolution of any application and business. It’s also inextricable from risk assessment. Every code change has the potential to introduce risk, whether in the form of a vulnerability, the expansion of your application attack surface, the introduction of a business logic flaw, etc. And as development and deployment velocity accelerates, the pace of change and, thus, the potential for risk also accelerates.

For security and compliance teams, this poses a massive challenge. How can you keep up with the rate of change to reliably surface and address changes that introduce risk—all without slowing down development?

In this post, we’ll explore material change detection at scale and why automated material code detection is crucial to application security and compliance—especially for organizations in highly regulated industries that are duty-bound to audit, track, and address material changes consistently.

Lifecycle of a change

While every code change has the potential to introduce risk, that doesn’t mean that every change will. Understanding the lifecycle of a code change is a crucial and sometimes overlooked practice to ensure code quality and security.

A change made to a codebase may be something trivial, such as changing the color of a button on your website or adding a comment. Alternatively, it could introduce a vulnerability or a material change—or both.

What makes a code change material?

Vulnerabilities (e.g., XSS, SQLi, OSS vulnerabilities, container vulnerabilities, IaC misconfigurations, etc.) are well-defined by various industry frameworks, and myriad automated tools exist to detect them. On the other hand, material changes are more difficult—if not impossible—to surface at scale using traditional application security and risk assessment tools.

A material code change can be defined as any change that can potentially introduce risk into an application. For example, a material code change could be:

• the addition of or changes to entry points (e.g., APIs)
• the introduction of new technologies and frameworks (e.g., DB or authentication framework)
• exposure of sensitive data (e.g., PII, PCI, PHI),
• new or unexpected changes within open source dependencies
• configuration changes to pipelines or infrastructure
• and more.

It’s crucial to be able to identify material changes because although they are not explicit vulnerabilities, they may expand or alter your application attack surface or introduce business or application logic flaws, thus potentially exposing your organization to risk.

Distinguishing material code changes from immaterial ones requires an in-depth understanding of application and software supply chain components (data models, entry points, pipelines, etc.), developer behavior intelligence, and continuous, change-based visibility across your codebase.

What makes a material code change a risk?

Classifying the level of risk of a material change requires an accurate understanding of the potential likelihood of it being a risk based on your application architecture, the nature of the change, and the developer that made it, as well as the impact such a risk would have on your business or application.

Understanding the nature and context of a material code change will help determine the level of potential risk introduced, thus informing the appropriate steps to address it. Because of the sheer volume of changes, being able to take the right-sized action based on the type and criticality of the material change will free up resources addressing low-risk changes.

Unlike vulnerabilities that, when identified, have straightforward dispositions (remediate, ignore, or accept), material changes are more nuanced. To assess the materiality of a change and its level of potential risk, teams still rely heavily on manual self-attestation methods, like risk assessment questionnaires. Only then can security teams take the necessary security measures, such as a penetration test, to ensure risk is accurately assessed and mitigated. This process is costly, complex, and can be at odds with development velocity.

To expedite application delivery without compromising security and compliance, we must take a different approach. CISOs, CIOs, risk managers, application security, software engineering, and product leaders need an automated way to monitor code changes, determine if they are material, and gauge the level of risk they introduce.

Automating material change detection and risk assessment for continuous compliance

Automating the detection and risk assessment of material changes can drastically speed up software delivery, ensure coverage and consistency, and streamline compliance. With immediate feedback on risk identification and mitigation, security teams can expedite the risk assessment process, and development teams can address problems proactively, accelerating development velocity without sacrificing security or compliance. Proactively identifying and remediating risk before code is pushed to production also reduces overall development costs.

Knowing exactly what’s changing and assigning specific procedures to specific types of material change is crucial for ensuring not just strong application security but also high-quality products and effective risk management. Subsequently, it reduces the burden required to prove to regulators or auditors that changes are addressed objectively and consistently.

For highly regulated organizations that must adhere to a strict level of quality and change management, automated material code change detection enables consistency, efficiency, and quantifiability when providing regulators with evidence around their change management strategy.

For security and compliance teams, automating the material change detection and response process not only saves time but also ensures better coverage, establishes consistency, makes tracking and reporting easier for audits, and speeds up feedback loops. For example:

• For PCI DSS, the automated process can highlight areas of the code that handle cardholder data, ensuring strong access controls and security measures are in place.
• For PCI Software Security Framework 1.1, teams can show that all software changes are identified, assessed, and approved, and all software versions are uniquely identified and tracked throughout the software lifecycle.
• Regarding NIST SP 800-218 and CIS, automated analysis can help enforce risk-based code review, fulfilling the standard’s guidelines.
• For the CRI Profile (also known as the “Banking Profile” or “Financial Services Profile”), which is an assessment framework based on NIST, teams can attest to the status of material changes, procure logs, audit trails, and backups of material changes, and can understand the impact of risky material changes.
• For GDPR compliance, identifying and securing areas where personal data is handled becomes a streamlined process, helping enforce data protection principles from the earliest stages of development and supporting privacy by design.
• For Matter Requiring Attention (MRA) processes, which are clearly defined by the US Federal Reserve and other regulatory bodies, teams can provide quantitative evidence of their protocols for evaluating, assessing, and addressing risk.
• For audits, teams can provide regulators and audit functions with an end-to-end audit trail of all material changes and risks associated with the code and development environment, easing the burden of responding to these requests.

With this approach, organizations can accurately classify risk, prioritize their findings, and allocate resources accordingly, ensuring a proactive and efficient risk-based approach to managing security risks in the face of constant change.

How Apiiro streamlines material code change detection

To help teams automate material change detection, Apiiro’s deep application security posture management (ASPM) platform provides real-time and continuous coverage, control, and visibility throughout the lifecycle of a change.

Apiiro automates material change detection by analyzing and correlating data from:

• Code (e.g., application code, infrastructure as code, open source dependencies, configuration files)
• Contributors (e.g., developer experience, behavioral patterns, permissions, and locations)
• Metadata (e.g., user stories, commit messages, pull request discussions)
• Third-party security findings (e.g., SAST, SCA, DAST, IAST)
• Security findings from manual processes (e.g., risk assessments, security code reviews, and penetration tests)
• Runtime sources (e.g., API Gateway, Kubernetes clusters)

Using deep, real-time code analysis and context from the above sources, Apiiro automatically flags material changes and triggers processes and guardrails based on the type of change, its business impact, and other factors. For example, if business logic changes in an HBI application, you may want to trigger a threat model. Or, if a new encryption framework is introduced, you may want to block the change and suggest an in-policy one. Knowing exactly what’s changing and assigning specific procedures to specific types of material change is crucial for proving to regulators or auditors that changes are addressed consistently and objectively. If a security questionnaire is still needed, by systematically calculating and gathering all of this data ahead of time, the number of questions that need to be answered is substantially reduced, and the accuracy of the responses can be drastically enhanced.

Being able to detect and address material changes automatically has the power to transform application security from a bottleneck to a catalyst for growth, enabling faster, secure delivery of applications to the cloud. It’s not just an evolution; it’s a revolution in how to approach application security in highly regulated industries.

⬩⬩⬩

Key takeaways:

• Understanding and differentiating between different types of changes is key to prioritizing and addressing risk.
• Material change detection and management requires deep code analysis and context from disparate sources in your tool stack – something that does not scale when assessing manually.
• Automating material change detection will help teams accelerate development velocity and ensure proper security coverage and consistency (detection, assessment, response).
• Rather than slowing down development, security and compliance teams can instead rely on automated advanced code and developer behavior analysis to comply with standards such as PCI DSS, NIST SP 800-218, CIS, SLSA, and even GDPR.

To learn more about automating your material change detection, schedule an Apiiro demo to see it in action.