By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
ToolAccuracy of FindingsDetects Non-Pattern-Based Issues?Coverage of SAST FindingsSpeed of ScanningUsability & Dev Experience
DryRun SecurityVery high – caught multiple critical issues missed by othersYes – context-based analysis, logic flaws & SSRFBroad coverage of standard vulns, logic flaws, and extendableNear real-time PR feedback
Snyk CodeHigh on well-known patterns (SQLi, XSS), but misses other categoriesLimited – AI-based, focuses on recognized vulnerabilitiesGood coverage of standard vulns; may miss SSRF or advanced auth logic issuesFast, often near PR speedDecent GitHub integration, but rules are a black box
GitHub Advanced Security (CodeQL)Very high precision for known queries, low false positivesPartial – strong dataflow for known issues, needs custom queriesGood for SQLi and XSS but logic flaws require advanced CodeQL experience.Moderate to slow (GitHub Action based)Requires CodeQL expertise for custom logic
SemgrepMedium, but there is a good community for adding rulesPrimarily pattern-based with limited dataflowDecent coverage with the right rules, can still miss advanced logic or SSRFFast scansHas custom rules, but dev teams must maintain them
SonarQubeLow – misses serious issues in our testingLimited – mostly pattern-based, code quality orientedBasic coverage for standard vulns, many hotspots require manual reviewModerate, usually in CIDashboard-based approach, can pass “quality gate” despite real vulns
Vulnerability ClassSnyk (partial)GitHub (CodeQL) (partial)SemgrepSonarQubeDryRun Security
SQL Injection
*
Cross-Site Scripting (XSS)
SSRF
Auth Flaw / IDOR
User Enumeration
Hardcoded Token
ToolAccuracy of FindingsDetects Non-Pattern-Based Issues?Coverage of C# VulnerabilitiesScan SpeedDeveloper Experience
DryRun Security
Very high – caught all critical flaws missed by others
Yes – context-based analysis finds logic errors, auth flaws, etc.
Broad coverage of OWASP Top 10 vulns plus business logic issuesNear real-time (PR comment within seconds)Clear single PR comment with detailed insights; no config or custom scripts needed
Snyk CodeHigh on known patterns (SQLi, XSS), but misses logic/flow bugsLimited – focuses on recognizable vulnerability patterns
Good for standard vulns; may miss SSRF or auth logic issues 
Fast (integrates into PR checks)Decent GitHub integration, but rules are a black box (no easy customization)
GitHub Advanced Security (CodeQL)Low - missed everything except SQL InjectionMostly pattern-basedLow – only discovered SQL InjectionSlowest of all but finished in 1 minuteConcise annotation with a suggested fix and optional auto-remedation
SemgrepMedium – finds common issues with community rules, some missesPrimarily pattern-based, limited data flow analysis
Decent coverage with the right rules; misses advanced logic flaws 
Very fast (runs as lightweight CI)Custom rules possible, but require maintenance and security expertise
SonarQube
Low – missed serious issues in our testing
Mostly pattern-based (code quality focus)Basic coverage for known vulns; many issues flagged as “hotspots” require manual review Moderate (runs in CI/CD pipeline)Results in dashboard; risk of false sense of security if quality gate passes despite vulnerabilities
Vulnerability ClassSnyk CodeGitHub Advanced Security (CodeQL)SemgrepSonarQubeDryRun Security
SQL Injection (SQLi)
Cross-Site Scripting (XSS)
Server-Side Request Forgery (SSRF)
Auth Logic/IDOR
User Enumeration
Hardcoded Credentials
VulnerabilityDryRun SecuritySemgrepGitHub CodeQLSonarQubeSnyk Code
1. Remote Code Execution via Unsafe Deserialization
2. Code Injection via eval() Usage
3. SQL Injection in a Raw Database Query
4. Weak Encryption (AES ECB Mode)
5. Broken Access Control / Logic Flaw in Authentication
Total Found5/53/51/51/50/5
Contextual Security Analysis
May 31, 2023

Security as Control, Composition, or Context

Security as Control, Composition, or Context

First, let me say thanks for visiting the DryRun Security blog! In this blog post, I discuss the various approaches the industry has taken to secure software and where we see the industry moving.

I spent the better part of my career between security and engineering teams, attempting to do devops while building cloud services for our customers. Getting it right wasn’t easy, and I often got it wrong. Coordination, communication, compliance, consultants, and coding. It’s all hard. (Not the alliteration; the work itself is hard.) Often the solutions we try don’t deliver what they promise, developers feel ostracized, and we realize that finding metrics to show progress is a bit of a proof-texting exercise.

When building at scale for customers, whether an enterprise or startup, it’s good to realize that security isn’t a solved thing or a single binary event of being secure or insecure. In the past, we've seen security as a control mechanism, where developers are often slowed down and forced to use tools they don't understand, like DAST and SAST. We've also seen the rise of composition, or Software Composition Analysis (SCA), which has helped us think about the components our applications use. However, I believe the best approach for modern applications is context - a concept called Contextual Security Analysis. We’ll get into Contextual Security Analysis a little later, but I wanted you to know where we are heading.

Context matters (source)

Ok, I think that’s enough foreword; let's dive in and explore these approaches and why Contextual Security Analysis is the way forward. (Foreword and forward… maybe this is a good spot to warn you to expect this type of horrible wordplay on this blog. 😂)

Security as Control

“Security as Control” is more than the tautological statement it appears on the surface.

In the early days of application security, the focus was primarily on control. Developers had to follow strict rules and use mandated tools, such as Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). While these tools can be useful in some cases, they often slow down development and force developers to run scanners or tools they may not fully understand. As a result, security becomes a bottleneck, increases cycle time, and incentivizes developers to make batching decisions.

This approach also tends to create an "us versus them" mentality, with security teams imposing restrictions on developers who are just trying to deliver features and functionality. Consequently, developers may disengage from the security process, leading to further communication breakdown and group collaboration. A classic devops silo problem.

Alternatively, some security organizations foster healthy relationships with their developers and even institute a “Security Champion” program. While this is better, it’s still a variation on the theme. It relies on distributing the same security tooling built for control  (DAST/SAST), but the primary audience is the developer that completed security champion school. This takes steps to solve team collaboration problems, but the results are varied across the industry regarding efficacy.

Security as Composition

The rise of Software Composition Analysis (SCA) has been a significant improvement over the control-based approach. SCA allows developers to reason critically about their applications' components, whether it's open-source libraries, third-party APIs, or other software dependencies. By understanding what components are used and how they are integrated, developers can better identify potential vulnerabilities and assess the overall security posture of their applications.

SCA has helped developers make more informed decisions about the components they include in their applications, leading to more secure software. However, it still does not address the root of the problem: understanding the context in which the application operates and how it interacts with various components, data, and services.

The question of “where?” is sometimes as important as the question of “what?” (source).

Security as Context: Introducing Contextual Security Analysis

Enter Contextual Security Analysis, a new approach to application security that focuses on understanding what an application does, what parts are sensitive, and how changes to the application may impact its security posture. This approach is ideal for modern applications, which are often distributed, microservices-based, and rely heavily on APIs and third-party components.

Contextual Security Analysis allows developers to reason about the security implications of their decisions within the context of the entire application. By understanding the relationships between components, data, and services, developers can make more informed decisions about security, leading to more secure software.

Here are some of the key benefits of Contextual Security Analysis:

  1. Better decision-making: By understanding the context in which an application operates, developers can make better decisions about security. They can prioritize protecting sensitive data and services, identify potential vulnerabilities, and evaluate the security implications of changes to the application.
  2. Improved collaboration: Contextual Security Analysis encourages developers and security teams to collaborate, sharing knowledge and insights about the application's context. This collaboration leads to more secure software and fosters a culture of shared responsibility for security.
  3. Greater agility: With a context-based approach, developers can quickly assess the security implications of changes to the application, allowing them to iterate and innovate more rapidly. This agility is critical for modern applications that adapt quickly to changing market conditions and customer needs.
  4. Increased visibility: Contextual Security Analysis provides a holistic view of an application's security posture, enabling developers and security teams to move from the binary view of secure or not secure and have a visual representation of how changes impact the system from routing and codepaths to functions and syntax.

In future posts will get into the details of how Contextual Security Analysis and where to start applying the principles within the practice inside your organization.  Stay tuned!

Shared context (source)

In Summary

Traditional views on application security have evolved from being seen as a control mechanism, which often hinders development, to a composition perspective, where we assess the components our applications use. Yet, both approaches fail to provide a holistic view of application security. The future lies in understanding the context – the essence of what our application does, what parts are sensitive or even brittle, patterns and anti-patterns, and a wide range of other useful data about code changes that help provide a window into how those changes might impact its security. This is what we call Contextual Security Analysis, a perspective that not only makes sense for modern, distributed applications but also fosters improved decision-making, collaboration, agility, and visibility.

Find out more about DryRun Security

Are you interested in learning more about Contextual Security Analysis?

Join our list to get access to the product, and by signing up, you'll receive insights delivered directly to your inbox, helping you better understand your application's context and make more informed security decisions.