Finding Risky Code Changes Inside Auth Functions

One way to determine if a particular code change is more risky than others is to evaluate which functions are modified when new code is presented for review. (n.b. We’re using the term “function” to represent routines, subprograms, subroutines, procedures, and methods.) We all have those particular functions in our code that, when they show up in a code review, we lean in and look closer. If you’re a multi-tenant SaaS, resource and data authorization (authz) functions usually cause the “lean in” to occur. Every engineer at a SaaS company knows that job one is to keep customer data separated.  

Another example of a code review that causes reviewers to “lean in” is anything around authentication (authn). Whether adding a new provider or changing an existing authn method. Just as we don’t want to cross-contaminate customer data, we also want to avoid scenarios where all the users are locked out, force password changes en masse, or introduce a vulnerability.  (There are dozens of other negative scenarios that can unfold when authn or authz goes wrong, but fear mongering isn’t our style.)

But, here’s the problem. Every day, our code changes immensely. Every day, we are asked to ship more and more features and bug fixes. Every day, there are more pull requests and code changes than any single application security expert could review.

While authn changes may not occur as frequently as say, authz—we need to know about both and use this as a data point when forming a risk assessment of the changes being introduced to our code base. Put another way, authn/z modifications are a very good indicator that the changes being introduced require careful consideration.

Meet your AI-Powered Sensitive Functions Analyzer

At DryRun Security, we’ve launched a new analyzer in our product that assists in the code review process by finding changes to sensitive functions, with a heavy emphasis on authn/z. Given that these functions are commonly used and are the first line of defense in securing applications, and for all the reasons above, we chose to start there.

It’s not only AI-powered, it’s also powered by our core approach to everything we do: Contextual Security Analysis (CSA). CSA is a paradigm shift in how we view application security. It evaluates each change using the SLIDE (Surface, Language, Intent, Detections, and Environment) framework to calculate the risk of any given code change.

Sensitive Functions in Action

Let’s say that in our local development environment we make a change to config/passport.js in order to perform some testing. Now, that change shouldn’t reach production and certainly should not makes its way into the pull request. However, as we all know, things like this occur all the time.

‍

passport.use(new OpenIDStrategy({    
apiKey: process.env.STEAM_KEY,    
// TODO change before we go to prod, using test providerURL   
//providerURL: 'http://steamcommunity.com/openid',    
providerURL: 'http://test.com/openid',    
returnURL: ${process.env.BASE_URL}/auth/steam/callback,    
realm: ${process.env.BASE_URL}/,    
stateless: true 

‍

The AI-powered Sensitive Function analyzer detects the change and flags it as a potentially sensitive modification because it touches authn/z. It will also tell you why that particular change caused it to alert.

If you are curious about why this change in particular was flagged, you can ask your Security Buddy right inside of the pull request. You can talk to to it by just using @dryrunsecurity in your comment. As an example:

‍

@DryRunSecurity Why is changing providerURL in my passport OpenIDStrategy 
configuration risky from a security perspective? 

‍‍

You’ll get an answer that explains the different risks associated with the change and it can provide developers with more context.

(If you’re in the DryRun Security Beta, you’re already seeing this in your code reviews …if you’re not, we’d like to join the beta; consider this your personal invite!)

Leveraging the Power of Contextual Security Analysis

CSA is a mechanism for us to ascertain whether or not a code change (pull request) exceeds your risk threshold using the totality of various data points available to us—including our own sensitive function analyzer.  

The idea behind CSA is that security teams, champions, and senior engineering staff have limited time to review code changes. By accurately surfacing just a few of the riskiest changes in a day or week these teams and individuals can better prioritize their efforts. Everyone loathes false positives because they eat up valuable time. Time that none of us are able to waste. CSA is designed to fix this problem entirely.

By using CSA and our various analyzers such as sensitive functions you can quickly identify authn/z risks as code is introduced for review. You’re not only protecting your customers and your business, you are building trust within your team, your company and your customers. And, just as importantly, you’re meeting your compliance obligations.

We encourage you to explore the benefits of CSA further by downloading our free Contextual Security Analysis Guide. Discover how to build CSA into your own security practice and make your application security proactive, precise, and developer-friendly.

Get Instant Access to CSA Functionality Right Now

We’d love to show you how DryRun Security can help you find risky auth function changes right away with our AI-powered Sensitive Function Check.

Discover how it can enhance your security posture and streamline your development process. To see it in action, request a demo or join the beta free right now.

Join us in revolutionizing application security, one code change at a time.