Today, we’ve launched our beta release of DryRun Security. I feel incredibly fortunate and this is a bit of a dream come true for me in many ways. Like so many of my counterparts in the software security world, I’ve experienced all of the challenges associated with the existing security tools out there including how we as an industry have chosen to implement them.
Those challenges are necessary parts of our evolution as practitioners but as we evolve, we find better ways to achieve our goals. This was a big part in my decision to leave the job as well as the people that I loved at GitHub and come join forces with James Wickett so that we could manifest these ideas into reality.
From the beginning, our objectives have been very clear:
- Build a developer-first tool (not just a tool marketed for developers)
- Make application security tooling extensible enough to keep pace with developer technology adoption
- Optimize for teams that perform high-velocity shipping
- Empower & force multiply the security team and their champions
- Contextualize all available information so that we can better evaluate risk in changing code
Now, I mentioned that today is a dream come true and I want to take a moment to really explain why that is*.* I’ve been in application security (AppSec) for most of my career in technology and have experienced its evolution firsthand. From the first DAST/SAST tools to the early days of OWASP and every imaginable SDLC security strategy and so much more... Basically, I’ve lived it all.
I’ve seen the good and the—well, I wouldn’t say “bad”—but not easy by any means. I believe this gives me a well-rounded view of our success and our failures, our past and present, and like many other seasoned veterans of the industry, I’ve got plenty of opinions on what we could be doing to improve our current status quo. Today, I’m blessed to see these ideas shift into reality.
A lot of the ideas behind what we are calling “Contextual Security Analysis” (more on that later) really started to crystalize while working with the incredible internal security team over at GitHub, where I managed our internal AppSec team. As new features or services were developed, we worked with developers on threat models, code reviews, and general consultation. What we did was important, the culture was amazing, and I loved it.
We experienced significant growth after being acquired by Microsoft, and suddenly, more code was shipping faster than ever. This exposed gaps in the ability of our existing processes and tooling to scale, and so we adapted. We focused more and more on risk reduction strategies rather than the thorough, but time-consuming, manual code review of all new features and services. We had to be picky about what code had our eyes on it. Human beings, especially ones with security expertise, aren’t scalable. Instead, we focused on ways to represent risk and methods to reduce it at scale.
GitHub is the place where the world stores its code. Code that powers the entire world.
It was incredibly important work because GitHub is the place where the world stores its code. Code that powers the entire world. The GitHub security team understands just how important their role is and how important the code of every organization—and every developer is. They also understand what is ultimately at stake if that software is stolen, tampered with, or lost. Software security was and is not optional, so any presented solutions needed to be highly practical and have maximal impact.
Without giving away too much about our internal processes, I will say that one part of performing risk reduction is identifying patterns that lead to the least favorable outcome in any given situation. Our challenge was identifying those risk patterns in changing code. We learned some of those markers often include things like:
- Changes that expand the surface of the application intentionally (or possibly, unintentionally)
- Changes that touch authentication or authorization in some way
- Complex changes, especially if rarely touched code is being modified at the same time
- Changes that introduce additional libraries, especially if they are likely to have security implications
- Certain frameworks have their own patterns for risk, such as certain files or functions being modified.
I wanted to democratize application security so that more risky pull requests would rise to the top and less risky ones would be able to be merged quickly.
As we built DryRun Security, many of these learnings echoed in my head. Even organizations with dedicated security teams needed a way to surface risk at scale and in the code they are working on every day. I wanted to democratize application security so that more risky pull requests would rise to the top and less risky ones would be able to be merged quickly. I knew that we didn’t want yet another overwatch enforcement tool; instead, we wanted a buddy by the developer’s side.
And like that, our product was born.
Meet Your Security Buddy
DryRun Security was created to give developers a buddy that warns, guides, and assists them with security activities at code merge time. It stays out of the way most of the time and lets developers know when they might want to dig deeper. When they do choose to do so, their security buddy will source answers from their organization’s documentation first so that we can provide platform and organization-specific guidance rather than generic information.
It’s built with a developer-first mindset, so it doesn’t emit event after event of CVEs and alerts. Instead, it fits in GitHub Pull Requests as a commenter.
Remember earlier when I mentioned Contextual Security Analysis (CSA)? Well, our buddy performs its analysis using CSA and it evaluates the diff in the PR using the SLIDE model. If this is the first time you are hearing about this approach, we have a whitepaper on the topic available for download at https://dryrun.security/csa, but the SLIDE model encompasses:
- Surface - includes routes, paths, lib checks
- Language - includes framework and language-specific checks
- Intent - looks for author intent, familiarity with the codebase, and other human elements
- Detections - evaluates for appsec issues (e.g., OWASP Top 10)
- Environment - uses the context of the function and purpose of the codebase
The above is just a brief summary, so I do highly recommend that you check out that guide if you are looking for additional details.
Today, we’re offering the first of several analysis engines with more coming online throughout the beta. Their purpose is to seek out markers and clues for risky code changes.
Let’s chat about a few of them.
Sensitive Codepaths
The first major feature request we had for our analyzers was the ability to detect when someone is touching a file they shouldn’t. This was actually a little surprising not because of the need for this type of analysis—it makes complete sense—just that it was such a priority for people and an overwhelming request.
Most applications have parts of their code that if modified by someone other than an approved team or individual(s) might lead to a significant gap in security. Sometimes, this is not just a gap in security but can actually cause significant outages.
If they’d had the sensitive codepath analyzer, the outage could have been prevented.
One of our users was very excited for our sensitive codepath analyzer. He told us how their organization experienced a critical outage a few months back and that if they’d had the sensitive codepath analyzer, the outage could have been prevented.
The outage occurred because an app configuration was changed by someone who had no prior experience with that part of the code. That individual wasn’t a part of the normal (short) list of people that would introduce such a change and they short-circuited the normal approval process. In the end, the company ended up with a significant outage on their hands.
I have experienced similar stories first-hand as have many others and so it made sense to build this feature first.
Sensitive Functions
This analyzer is looking for changes to functions that are deemed sensitive in nature. Every application has functions within their code that if modified could represent risk to an organization and that is the essence of this analysis. Currently, we leverage probabilistic models in tandem with our own knowledge-base to identify these functions.
Today, we focus primarily on changes to authentication and authorization. However, near-future iterations will use what we know about the application such as its underlying technology stack, organization specific information from their own knowledge-base, and our probabilistic models & knowledge-base to determine sensitivity of the changing code.
Sensitive Files
Similar to sensitive functions, files exist within an application that are considered sensitive. If modified, they represent a significant risk to the application. These usually fall into one of the following categories:
- A file that would be considered highly specific to that application and that is known to contain important security logic. Example: A brittle, lengthy, and rarely touched file used for access control
- Web framework’s often have important configuration files or other types of files that have significant impact on the security posture of an application. An example would be a ‘settings.py’ file in Django applications which contain hashing routine decisions, Cross-Site Request Forgery strategies, audit log settings, serialization formats, and much more.
- Similar to web frameworks, application libraries often have their own configuration and setting files that if modified could weaken the application’s security posture. An example would be ‘Passport.js’ which has a commonly used pattern where developers utilize a configuration file to manage their authentication strategy.
Putting it all together
As we build more and more of these analysis engines we will utilize all of the available output from them to make risk scoring decisions and surface them in pull requests. Our security buddy can then help guide developers through taking the appropriate action and resolution. Lastly, the DryRun Security portal can be used to manage it all and provide organizations with a way to demonstrate proper change control should the need arise.
Join the Beta
As I mentioned at the very beginning of this article, today is a very special day. We are now in open beta and available in the GitHub Marketplace. If you’re ready for better application security for developers, I’d love for you to join the beta!
Visit https://github.com/marketplace/dryrun-security-app to get DryRun Security installed and running on any PRs in seconds!
{{install-button}}
.webp)
