Project Kodiak: Shifting Application Security Left at Enterprise Scale

By Florian Noeding, Principal Security Architect

In order to remediate security vulnerabilities efficiently, they should be identified and mitigated as early in the product development cycle as possible. But within a large enterprise, this can be difficult because development teams often use a wide range of disparate tools, and even build on different platforms, cloud or otherwise.

That’s why Adobe’s application security strategy focuses on “shifting left” to implement security checks earlier in the development lifecycle, enabling our teams to proactively and preventatively address vulnerabilities before they impact our customers. Project Kodiak, an internally developed collection of source-code scanning capabilities, helps Adobe discover vulnerabilities at enterprise scale and enables our product developers to better remediate issues before deployment.

What is Project Kodiak?

Based on the “Security as Code” concept, Project Kodiak establishes a centralized mechanism for our security team to provide feedback on code to product engineering teams. Its rapid rollout capabilities allow new security rules to be implemented within minutes, enabling the scanning of tens of thousands of code changes daily.

Integrated into our product teams’ workflows early in the development cycle, Project Kodiak is an orchestration engine that reacts to pull requests and commits in our source code management systems. It then scans the source code using multiple tools and presents its findings as inline feedback on pull requests and via a dashboard to the developer.

Why We Built vs. Buy

You may be wondering why we decided to develop Project Kodiak instead of purchasing a source code analysis platform. We found that the integration effort of various source code analysis tools would be complex in an enterprise environment. Many vendors offer all-in-one solutions that combine multiple capabilities, but this wouldn’t allow us to use a best-of-breed approach for our tooling, as different vendors have varying strengths and weaknesses. Furthermore, using different vendors would mean burdening our developers with multiple noisy interfaces. So, we created our own single pane of glass on top of these capabilities. This gives us the fine-grained control to limit noise and highlight only the security findings worth fixing.

In addition to minimizing noise and maximizing control, we recognized that it was important for developers to receive feedback in an actionable, relevant, and timely fashion. As a result, Project Kodiak is largely focused on minimizing false positives so that developers can concentrate on the issues that present the greatest risk. By ensuring low false positive rates and providing feedback in less than five minutes of build time, Project Kodiak also helps us build trust and further collaboration with our development teams.

Project Kodiak in Action

Today, Project Kodiak offers three (3) primary capabilities:

• Software Composition Analysis (SCA): Detects vulnerabilities (CVEs) in third-party dependencies
• Static Application Security Testing (SAST): Pinpoints vulnerabilities in first-party code
• Secrets in Source Code Detection: Identifies credentials or other sensitive data

In the pull request workflow above, developers start by writing code and testing it locally. Next, they commit and push it to a code repository. Here is where Project Kodiak comes into play: Instead of directly integrating it into the codebase, Adobe’s developers follow a peer review model by first creating a pull request. This pull request captures any changes made by the developer and allows their coworkers to share feedback. Here, Project Kodiak is also asked to provide feedback on any code changes by using SCA and SAST analysis tools. This feedback is presented as if it came from a human coworker in a fully automated way. After gathering feedback, the developer merges the new code to implement changes into Adobe’s products or services.

Now that you know where Project Kodiak fits in, let’s break down the scanning and feedback process:

1. Scanning & Issue Detection

After a developer has created (or updated) a pull request, our source code management system informs Project Kodiak’s orchestration engine. The orchestration engine then sends a message to scan workers that download the relevant source code for scanning. Next, they each execute their respective scanning tool, generating a differential analysis to highlight net-new findings between the Git base and head revisions. Finally, they return any findings in the Static Analysis Results Interchange Format (SARIF), which provides a unified way to exchange analysis information in a tool-agnostic fashion.

2. Post-processing

Once Project Kodiak completes scanning the source code, it removes duplicate findings, minimizes false positives from the raw feedback and correlates the different scan engines’ findings.

3. Inline Feedback & Dashboard

At the last step, the Project Kodiak orchestration engine collects the results and presents them as inline feedback and via a dashboard to the developer, giving them an at-a-glance view of any vulnerabilities found.

Disclaimer: These screenshots do not contain real data or findings.

Results So Far

Project Kodiak has brought numerous advantages not only to our security teams but also to Adobe as a whole, including:

• Streamlined Auto-Onboarding: Instead of charging developers with the task of onboarding to security processes, our approach automatically onboards much of our development teams and seamlessly integrates with their development workflows. As a result, we have achieved an exceptional onboarding rate of over 96.6% for all active Git repositories across Adobe.
• Safety Net Coverage: Covering a diverse technology stack with SCA and SAST can be challenging, but Project Kodiak acts as a safety net for all supported technology ecosystems. Additionally, it serves as a training platform, helping us educate developers about aiming to eliminate potential security issues from production.
• Automated Detection and Prevention: Our internal security researchers and development teams can leverage their expertise by codifying security practices. Instead of relying solely on manual reviews, we can automate the process of detecting security issues by using a combination of open-source, commercial, and Adobe-customized rules. This includes identifying coding anti-patterns and vulnerable data flows.
• Support for Security Research and Incident Detection: Project Kodiak incorporates a code search feature that employs regular expressions and semantic queries, providing invaluable support for our security research and incident response efforts. This functionality aids in uncovering relevant code snippets and patterns to investigate potential vulnerabilities or incidents.

Project Kodiak plays a vital role in our application security strategy by helping us identify security risks through early integration and feedback. By shifting security left and empowering our development teams to make informed security and design decisions early on, we not only establish trust, but we also proactively try to address vulnerabilities before they can impact our customers. With Project Kodiak, we endeavor to stay one step ahead of adversaries, enhancing our overall security posture and reinforcing our commitment to delivering secure applications.

Stay tuned for my next blog post where we’ll dive deeper into the intricacies of implementing Project Kodiak and the considerations and tradeoffs that come with building such a system.