Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

What We Can Learn from the Accellion Breach

Close up hourglass sand almost done


News about the recent Jones Day / Accellion vendor data breach highlights just how difficult third-party risk management (TPRM) is in practice. With this particular breach, Accellion’s “legacy” large file transfer product, FTA, was identified as the affected target. In this article, I’m going to cover a few interesting observations from some of the communications used to describe the event and mention five ways you can fortify your TPRM program to enhance your due diligence when evaluating vendors.


The official FTA Security incident press release, from Accellion was where I started. By examining some of the language they used, I hoped to better understand what really happened. Surprisingly, one of the first things that stood out was the terminology used to describe the affected product:

  • legacy

  • 20-year-old

  • end-of-life

Contrast this with the terminology used to describe their newer and preferred solution, the “kiteworks” platform:

  • entirely different codebase

  • state-of-the-art security architecture

  • segregated, secure development process

As a result, Frank Balonis, Accellion’s CISO recommended “all FTA customers to migrate to kiteworks...We remain committed to assisting our FTA customers, but strongly urge them to migrate to kiteworks as soon as possible.”

To Accellion’s credit, they are working with at least one managed bug bounty provider to assess their products and it’s hard, if not downright unfair, to criticize them for trying to migrate customers to a newer and conceivably more secure product offering. In any case, there’s no benefit in playing the blame game after the fact. The question then becomes, what could Jones Day have done to avoid falling victim to the consequences of relying on a vendor with legacy, 20-year-old, end-of-life software? And how can other organizations learn from this story to better protect themselves?


As mentioned earlier, Accellion does participate in a managed bug bounty program, but this breach is related more to third-party risk management. What’s the difference, and what does it have to do with bug bounties?

This led me to think a bit more about how this breach relates to the bug bounty delivery model. As mentioned in one of my previous posts about crowdsourced security, I believe that bug bounties have their place in the security management ecosystem and provide their customers with an opportunity to remedy a vulnerability, ideally, before it’s exploited.

However, third-party risk management is a complicated use case that doesn’t really fit well with the traditional bug bounty delivery model. One of the biggest hurdles is that most contractual agreements with third-party vendors are unlikely to allow unfettered, continuous testing – for a bug bounty – against their environments on behalf of their customers.

Not only do they not typically allow access, but even if they did, a single point-in-time test hardly provides the ongoing vigilance an organization would need to consider a third-party vendor secure. So, while Accellion took steps to manage risk by enrolling in a bug bounty program, there’s more work to be done to provide the appropriate assurances to their customers that their products are indeed secure.


At its most basic form, a software bill of materials (SBoM) includes all proprietary, open-source, third-party libraries, and associated software licenses that comprise a company’s “product,” which could be purely software or embedded code within a device. The process is similar to how we think about the dynamic nature of the attack surface – software composition works in much the same way.

While automated tools are available to help generate a software bill of materials inventory, they can also turn into an exceptionally challenging endeavor if the company develops or manufactures hundreds or thousands of products with an equally diverse number of versions and combinations of components. This now becomes a due diligence effort to ensure the SBoM remains up-to-date, relevant, and available to inform and assess risk.

Having an SBoM at the ready is a great start, but, as the old saying “garbage in, garbage out” goes, the quality, accuracy, and completeness of this dataset is a key step toward a successful risk mitigation strategy. An updated SBoM allows you to cross-reference any potential issues against vulnerability databases or threat intelligence feeds that may indicate your business is at risk. The benefit of this is that you can discover some actionable insights to actually help you secure against those risks by analyzing feeds in a single stream.

Due to the terms mentioned earlier in Accellion’s security advisory, SBoM is a relevant topic for this breach – not only for Accellion itself, but also for Jones Day and third-party risk management in general. While there’s no way to know definitively if SBoM is used as selection criteria for their vendors, it most certainly should be moving forward for Jones Day. It’s apparent Accellion was preparing to decommission the affected FTA product, which also stands to reason that the contents of FTA’s SBoM would have reflected a legacy, 20-year-old product that would have indicated its reaching end-of-life status. All key terms that should raise a red flag to your security team when choosing a solution from a vendor that may interface with sensitive customer data.


This article is not intended to pass judgement on Jones Day, Accellion, the affected product, or the breach itself. Instead, this news is just the latest example we can use to learn from and improve our approach for mitigating third-party risk – a challenging topic itself. So, what steps can your organization take to manage third-party risk? Here are five takeaways that will help you evaluate how serious your vendor is about security:

  1. Take the time to research and review past security disclosures from your vendors. Do they appear genuine, transparent, and embrace the reality that breaches happen? If so, then it’s a good sign that they’ve likely got a plan in place to effectively respond to, and limit the damage caused by, a breach. However, stay vigilant and trust but verify as appearances can be deceiving.

  2. The existence of a bug bounty program is good, but it’s not enough. While your vendor may be enrolled in a managed bug bounty program, it’s not a one-to-one replacement for security assurance, and certainly presents challenges in a third-party risk management use case.

  3. Ask whether your vendor maintains a Software Bill of Materials (SBoM). As with a bug bounty, the mere existence of an SBoM isn’t enough. Inquire about how your vendor keeps their SBoM current (preferably through automation) and what benefits they receive from doing so. If the answer is “for compliance” and not associated with proactively managing risk, then that could be a red herring.

  4. Don’t forget about the Secure Software Development Lifecycle (S-SDLC). Inquire about how your vendor implements secure software development principles when building products. If possible, ask to speak directly to engineering leadership and look for a mature, documented, and repeatable process.

  5. Remember, breaches happen. While the statement from Jones Day indicates that the sensitivity of the data involved in the Accellion breach is “mundane,” it behooves an organization to take note of the sensitivity of data that a vendor will have access to and inquire about the controls used to protect it. Breaches happen, but security assurance isn’t about perfection; it’s about staying vigilant and maintaining an acceptable level of risk across your organization.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.

Joe sechman

About the author, Joe Sechman

Bishop Fox Alumnus

Joe is a Bishop Fox alumnus and brought over 20 years of experience to his role as Associate Vice President of R&D. He was responsible for nurturing a culture of innovation across Bishop Fox. Over his career, Joe has amassed many security certifications, delivered several presentations, and has co-authored multiple industry publications with groups such as ISC2, ISACA, ASIS, HP, and IEEE.

Additionally, Joe is a prolific inventor with nine granted patents in the fields of dynamic and runtime application security testing, attack surface enumeration, and coverage (U.S. Patents 10,699,017, 10,515,219, 10,516,692, 10,515,220, 10,423,793, 9,846,781, 10,650,148, 10,587,641, and 11,057,395). Prior to joining Bishop Fox, Joe held leadership positions with companies such as Cobalt Labs, HP Fortify, Royal Philips, and Sunera LLC (now Focal Point Data Risk). Earlier in his career, Joe served as the lead penetration tester within SPI Labs at SPI Dynamics where he cut his teeth alongside some of the best and brightest application security industry professionals. Joe received his Bachelor of Business Administration degree in Management Information Systems from the Terry College of Business - University of Georgia.
More by Joe

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.