Finastra implemented an application security solution that naturally aligned to the way that their developers work.

The Challenge

Ensuring 100% Code Coverage  

Finastra is a large organization that has developed products for the better part of 3 decades. This means that we have a wide range of languages, technologies, and frameworks in the products we develop – each critical financial product being used by our more than 6000 customers across the globe.

Previously, because we were leveraging CI/CD pipeline-oriented products, our security team was very dependent on DevOps teams to make pipeline configuration changes to ensure that each repository and product was being scanned. With such a diverse and robust technology stack, we were hard pressed to answer the critical question: do we have full application security coverage of every product? At our size, we could not afford to manually review coverage.

Prioritizing Application Security Risks

Our existing application security tool set gave our security team the ability to discover known vulnerabilities based on CVSS severity. But what we lacked was a deep understanding of context – especially for Software Composition Analysis (SCA) risks. For example, it was hard to know if a risk-exposed product was deployed to customers or not. There was no information on the temporal aspects of a vulnerability. What is the likelihood of exploitation? Has it already been exploited?  

This lack of contextual depth led to a lot of back and forth with developers as our security team would surface critical vulnerabilities, but the developers were not provided a deep understanding of why the vulnerability was or was not important or how to fix it.  

Disjointed Developer and Security Workflows  

The back and forth between security and developers was also completely unsupported by our application security tool set. We lacked any deeply defined workflows, and especially unification of workflows across the scanners we were using. Because we were implementing in CI/CD, if there was a known vulnerability, then the build would fail. That is how the developers would know about the vulnerability.  

The Solution

100% Code Coverage from Day One

Arnica integrates directly into our source code repositories. It supports our languages and frameworks. We don’t need to ask ourselves whether a particular repository or product is being scanned or not. And better yet, any new repository added down the line is covered automatically. The security team then has unwavering confidence that all code is being scanned.  

The upshot of full code coverage is that it allows developers to move a lot more quickly because we’ve been able to remove unnecessary time spent going to development teams to understand if there is a gap and then waiting for any gaps identified to be fixed. Development teams are able to move more freely, knowing that they’re covered by our Arnica deployment, no matter where they are writing code.

Rich Prioritization Aligned to Context & Business Importance

Another time saving improvement for our team has been Arnica’s depth of context and prioritization provided to both security teams and developers. For security, we are able to navigate the sum of all findings based on EPSS, CVSS, KEV, business importance and more. It allows us to gain a clear sense of what our biggest exposure points are and to address them immediately.

For developers, the importance and priority of a vulnerability is clear and communicated to developers so that they are empowered to understand why a risk might be critical beyond just the severity score. The fact that Arnica is integrated into the repositories and provides feedback on vulnerable code as soon as code is pushed empowers our developers to take action on a given risk without leaving their workflow. Beyond that the developer is given clear paths to resolution for a given risk so that they can choose which approach best suits the given situation. This is just one example of how Arnica shifts left in a way that is natural for our developers.

Developer-Native Security Workflows

With its integration into chat tools – Arnica allows our security team to configure notifications to be sent directly to the developers and security champions. Developers appreciate that we’re able to, with Arnica, provide feedback early and provide it with the tools they’re already using. It’s equally important that we, on the security side, can configure the notifications to ensure that we’re not bombarding developers with notifications that we do not pose high or critical severity risks.

Beyond chat, developers are used to getting feedback on their PRs from their team members. Arnica does the exact same thing but in a way that saves our developer's time. For our developers, it feels as if they’re interacting with a colleague providing security guidance as they push code. Based on the feedback they are getting, and depending on the risk severity and product, we are using Arnica to empower developers to tell us whether or not an issue needs to be fixed or not. Conversely, for certain products or severity levels, we require review for any dismissal.  

How Arnica Eliminates Friction and Enhances Efficiency

Without Arnica, our developers would surely either need to log into a new tool or end up buried by security alerts. An entirely separate exercise would be required for code security efforts. Developers would have to allocate a certain amount of time per week. But instead, Arnica acts as a security assistant. Rather than being a blocker to development, it’s facilitating the build process, giving developers actionable and valuable feedback early. Arnica has helped us build a true culture of security within engineering.  

Another aspect of Arnica that has been impactful is the fact that it has helped us consolidate tools across our software supply chain security efforts. We had different tools for generating SBOM, for code risks like Software Composition Analysis (SCA), and for looking at operational security of third-party libraries. The fact that Arnica provides all of this within a single platform with consistent policy implementation and finding outputs has been hugely helpful to making us a better and more efficient team.  

At the end of the day, the reason we’ve taken to Arnica across both security and engineering teams within Finastra, is that Arnica is “shifting left” the right way. We are no longer unsure if our code is being scanned or overwhelmed by indiscriminate alerts. Developers aren’t confused about why a given risk is important or how to fix it. Arnica has brought an application security approach that is natural.