CIO Influence Interview with Aaron Bray, Co-founder and CEO of Phylum

Aaron Bray, Co-founder and CEO of Phylum shares about zero-day attack strategies, the process of identifying malicious code within software packages, and more in this chat.

———-

Hello Aaron, welcome to our CIO Influence Interview Series. Can you take us through the key milestones of your career and how they’ve shaped your leadership in software security?

I started my career working more generally in the IT space, but within the DoD, where security was a core part of everything. As I transitioned into the software development world, security in that realm became a more prominent part of my focus. As my career progressed, I spent more and more time at the intersection of software development and cybersecurity, and later on, I spent more time working in the offensive space (which included my time working with the red team at Sony), which I think has given me a very unique perspective on security more broadly, and especially in the realm of software security. As with many security disciplines, it can be a very challenging space to transition into without some experience around how software development occurs.

Also Read: CIO Influence Interview with Eduard Frank, CTO of Scanbot SDK

Can you explain how Phylum identifies malicious code within software packages? What kind of malicious activity does the platform detect in real-time?

By looking at a combination of data about value chain behind the software packages – things like metadata about the contributors and the packages, the source code of the software, and similar things. Some of the types of malicious activity identified includes both “access” type attacks, such as typosquatting, or dependency confusion – activities that enable an attacker to gain access to execute within an organization – and also the types of behaviour that an attacker would engage in once execution has been gained: harvesting intellectual property, passwords, server or user data, and similar things.

Zero-day attacks remain a significant threat. What strategies do you believe are most effective for organizations to protect themselves?

First and foremost, I’d say the biggest things to focus on are education & applying a first principles approach to security – understand your attack surface, reason about the risk exposure, reduce the surface area (ways that an attacker can get in) and the segment the permissions of personnel within the organization (e.g., make it more difficult for attackers to expand if they manage to make it in). Another way to think about it would be – what are the ways someone could gain access to your systems, and how can they be secured? In the context of cloud systems, it might be the posture of the services that can be reached from the open internet. For application security, third party tools, libraries, and services would be a good place to start, etc.

With AI tools increasingly used for code generation, what specific risks should security teams be aware of, and how can they mitigate them? 

The biggest risks associated with AI generated code fall into two buckets: security issues with outputs, and issues with inputs. Security problems with AI tool outputs cover any issues with the generated software – primarily, the code itself and any referenced package dependencies, which could contain vulnerabilities, defects, or malicious behaviour, or in severe cases, could open the organization up to novel attacks. Additionally, AI tools are generally unaware of any other contextual problems with the solutions they suggest, which could result in code duplication from other places, resulting in legal risks, or the inclusion of software that is licensed inappropriately for the use case. Issues with inputs are a bit different – the primary concerns here would be around exposing proprietary data to external models (which may be trained on customer-provided input) which could then be leaked, and potentially issues related to the prompts themselves – which could result in output that does not behave as expected.

 We’d love to hear about how Phylum’s real-time threat feed integrates with existing security tools to enhance threat detection.

 An interesting aspect of the type of attacks Phylum detects is that there are actually multiple points where detection can occur – at the network boundary, when the packages are being downloaded, at installation time, after changes have been committed during the development process (essentially, in CI/CD), and then retroactively. This means that the collection of IOCs Phylum surfaces can be incorporated into tools that operate at each of those points – tools in the CASB space can enable the detection of bad software when developers download it, XDR solutions can incorporate the Phylum threat data to identify compromises that have occurred on endpoint devices, and it can be connected into SIEM or ASPM solutions to be correlated with data from other sources.

Also Read: CIO Influence Interview with Bryan Litchford, Vice President of Private Cloud at Rackspace Technology

 What’s your take on the integration of security into DevOps (DevSecOps)? How can development teams adopt security practices without slowing down innovation?

The best way for development teams to improve security without slowing down innovation is to incorporate security as early in the development process as possible, in order to ensure that developers are making better security choices at the beginning, rather than having to spend cycles remediating mistakes down the line. This has been a core part of how we at Phylum have developed our tooling – from providing some tools for developers to check policy during package installation, to the development of a package firewall – providing capabilities for developers to check their decisions up front reduces the need to revisit design decisions down the road.

 Looking ahead, highlight five technologies you believe will have the biggest impact on software supply chain security in the next five years.

• Generative AI – Google has recently said that Generative AI solutions are now writing 25% of code generated at Google, and more companies will almost certainly adopt as well. These solutions, however, don’t have the context and understanding that human developers do, and rely on human interaction to ensure that the code they generate functions properly. Academic research in this space is still in its infancy, but early indicators show major problems on the horizon from a security perspective in this area.
• Application Security Tools that deal with external artifacts, such as SCA, ASPM, etc. – As attacks in the space continue to ramp up and diversify, appsec tools will need to continue to adapt: solutions will need to become more real-time and data driven in order to identify issues and prevent compromises, and will need to be incorporated earlier in the development process.
• Package Managers – These are the places where developers publish and host packages – think, marketplaces for open source software that developers frequent. These marketplaces are frequently used for software supply chain attacks, since organizations worldwide rely on them for software development. While most of these solutions were not designed with security in mind, they have just begun the journey to add protections to how software is deployed and consumed. It is a slow process, as these organizations are bureaucratic and very community-driven, but are likely to have a big impact on raising the bar for security in the context of the software supply chain.
• Code Repositories – The place where development work happens, and where code is hosted. Security will need to continue to become a more integral part of these solutions, as more companies consider outsourcing, and deal with new challenges relating to their development workforces and ensuring that processes are enforced.

CI/CD solutions – This is where software is built, and as with code repositories, will ultimately need to have more security and isolation baked in. It has already been at the center of several major compromises, including SolarWinds and codecov, and needs additional tooling in order to ensure that the current gaps are addressed appropriately.

[To share your insights with us as part of editorial or sponsored content, please write to psen@itechseries.com]