Guarding against supply chain attacks [Q&A]

In recent years supply chain attacks have become much more commonplace, targeting vulnerabilities and getting legitimate apps to distribute malware.

We spoke to Nir Valtman, CEO and founder at Arnica, to discuss the issues these attacks raise and how organizations can defend against them.

BN: What are the main challenges companies face when protecting against supply chain attacks?

NV: The rise in software supply chain attacks over the past five years has surprised everyone. There are four main challenges to protecting against software supply chain attacks:

Context is key. An increase in software supply chain attacks led to the need for additional security tools, turning quickly into alert fatigue for security and DevOps teams. The security industry and many open-source projects responded with opinionated best practices to secure the various components of the development ecosystem, such as source code management, CI/CD pipelines, and artifact management systems.

What we learned is that following best practices without any context, and without taking into consideration how each organization operates, can be devastating for security and engineering teams. For example, not all source code repositories carry equal business importance; perhaps only the ones that pose a significant operational or security risk should have a strict branch protection policy.

Developers are being targeted. A developer compromised through an account takeover or insider threat can potentially propagate to a bigger breach. For example, source code exfiltration may not be considered a high-severity breach, but if hardcoded passwords to the production environment are detected in these repositories, it escalates the breach to critical severity.

Developer permissions are overlooked. Due to the pace of cloud-native application deployment, access to code can equate to access to production. But, secure developer access to source code continues to be a challenge. On the one hand, security teams are reluctant to harm the development velocity with permissions controls. But on the other hand, many breaches would have been contained if preventive actions had been taken to reduce excessive developer permissions.

Vulnerabilities in dependencies. The security industry has learned the hard way that eliminating vulnerabilities in third party dependencies is as important to software supply chain security as eliminating vulnerabilities in your own source code. The proliferation of malicious third party software dependencies increases the need to detect and prevent the execution of them in the development ecosystem.

BN: What actions should companies take to better protect themselves against supply chain attacks?

NV: There are four key steps. Threat model your software supply chain. Identify which assets are most important to protect and who the appropriate owners are to handle security issues when they arise. Define the response to vulnerabilities that result from static application security testing (SAST), software composition analysis (SCA) and other code security tools.

Establish visibility of all associated risks in your software supply chain, with the context based on the historical behavior of each engineering organization.

Minimize the attack surface of a compromised developer account by reducing developers’ permissions to minimum and identify any anomalous behavior associated with each account. It is equally important to ensure that developers have a fast, easy way to gain permissions so as to not disrupt their flow.

Automate the work for mitigating risks in the software supply chain. For example, mask a newly pushed hardcoded secret to the repository or add a comment to a pull request when a risky code is introduced.

BN: What are the most common problems dev teams face with utilizing security tools?

NV: The tensions between security and development teams are well documented, with security often being perceived as the one to blame for the disruption of development velocity. In theory, these tensions can be avoided altogether if security tools could avoid specific pitfalls like too many contextless alerts, untargeted notifications and blame, and a lack of ability to 'fix it' from the tool. However, modern security tools, much like any tool that relies on machine learning models, will inherently generate at least some false positive results.

In all my years as a CISO and VP of Application Security, I've never encountered a static application security testing (SAST) tool that provides 100 percent accurate results. For developers, a newly deployed SAST tool that doesn’t provide context or priority for each identified risk can create a mountain of to-do list items that require developer focus to even understand, let alone address.

Additionally, application security tools typically require CI/CD pipeline integration or IDE plugin installations. This requires more work for engineering teams and tends to take a 'blunt instrument' approach to notifications. If you look at tools that run in the CI/CD pipeline, they tend to provide feedback broadly for everyone to see. This is not only ineffective in empowering the most well-equipped developer to fix the issue but, how would you like to be blamed publicly for introducing a new high severity vulnerability in the code without being empowered to easily fix it?

Lastly, due to the economic downturn, headcounts are being reduced, which adds an additional challenge for security teams trying to identify the right people for the right tasks at the right time. Developers don't want yet another Jira ticket -- they need 'working hands' in the form of automated mitigations instead of recommendations or to-do list items to be added to their backlogs.

BN: How does Arnica detect and protect against anomalous developer behavior?

NV: Arnica builds a behavioral profile for each developer. When a developer pushes new code, Arnica analyzes it against the developer profile and takes an action based on org-specific policies. For example, when a developer pushes code with seemingly different coding patterns, Arnica will send a message via Slack/Teams directly to the developer and ask if the developer pushed the code recently. If the developer confirms, Arnica will teach the model using the new commit; if the developer says it was not them, a security incident will be kicked off automatically.

It's important to mention that multiple workflows can be used within Arnica at the same time to add layers of protection. An example workflow might be adding a comment on a Pull Request when anomalous behavior is detected or adding a reviewer to the Pull Request to ensure that risky changes are reviewed thoroughly.

BN: What are the challenges of integrating security into CI/CD pipelines?

NV: As a starting point, the integration of security into CI/CD pipelines requires code changes. This means that 100 percent coverage across all pipelines is extremely hard to achieve and maintain and requires upfront and ongoing engineering effort.

Once the integration is complete, time sensitive actions, such as mitigating a new hardcoded secret, will take longer to execute due to the full context of all jobs in the same pipeline. Additionally, if the security scanners are kicked off only when there is a Pull Request, development velocity can be negatively impacted because feedback is too late in the process (instead of at every code push).

Lastly, the results of the pipeline execution are presented to all users with access to the source code repository, indiscriminately. This is far from ideal; certain security findings themselves are sensitive and should be presented only to the relevant personnel. For example, a newly detected hardcoded secret should be shared only with the developer that pushed and can mitigate that sensitive secret, rather than the entire engineering organization.

BN: What is Pipelineless Security, and what are the benefits?

NV: Pipelineless Security is a new model of software supply chain security that facilitates 100 percent coverage from day one, increases development velocity, and directs accurate results to the appropriate communication channels all without any necessary pipeline configuration changes or IDE plugin installations.

Pipelineless Security provides users with dramatically improved ease of deployment and operation through automated mitigation workflows. Despite its vast UX improvements and ease of use, Pipelineless Security approach is built on top of a set of technically complex guardrails that listen to all events occurring within Source Code Management (SCM) tools in order to provide highly contextualized, prioritized, actionable mitigation actions.

The three core principles of Pipelineless Security are:

• Listen to all important events, e.g. subscribe to code push, pull requests and audit events.
• Kick off out-of-band automated guardrails, e.g. remove a newly pushed hardcoded secret
• Provide isolated feedback, e.g. notify the code pusher and security team upon identifying a hardcoded secret (and no one else) or introducing a new code vulnerability.

Image Credit: frank_peters/ Shutterstock