Showing posts with label Threats. Show all posts
Showing posts with label Threats. Show all posts

22/03/2026

Claude Code Hooks: The Deterministic Security Layer Your AI Agent Needs

Claude Code Hooks: The Deterministic Security Layer Your AI Agent Needs
> APPSEC_ENGINEERING // CLAUDE_CODE // FIELD_REPORT

Claude Code Hooks: The Deterministic Security Layer Your AI Agent Needs

CLAUDE.md rules are suggestions. Hooks are enforced gates. exit 2 = blocked. No negotiation. If you're letting an AI agent write code without guardrails, here's how you fix that.

// March 2026 • 12 min read • security-first perspective

Why This Matters (Or: How Your AI Agent Became an Insider Threat)

Since the corporate suits decided to go all in with AI (and fire half of the IT population), the market has changed dramatically, let's cut through the noise. The suits in the boardroom are excited about AI agents. "Autonomous productivity!" they say. "Digital workforce!" they cheer. Meanwhile, those of us who actually hack things for a living are watching these agents get deployed with shell access, API keys, and service-level credentials — and zero security controls beyond a politely worded system prompt.

The numbers are brutal. According to a 2026 survey of 1,253 security professionals, 91% of organizations only discover what an AI agent did after it already executed the action. Only 9% can intervene before an agent completes a harmful action. The other 91%? 35% find it in logs after the fact. 32% have no visibility at all. Let that sink in: for every ten organizations running agentic AI, fewer than one can stop an agent from deleting a repository, modifying a customer record, or escalating a privilege before it happens.

And this isn't theoretical. 37% of organizations experienced AI agent-caused operational issues in the past twelve months. 8% were significant enough to cause outages or data corruption. Agents are already autonomously moving data to untrusted locations, deleting configs, and making decisions that no human reviewed.

NVIDIA's AI red team put it bluntly: LLM-generated code must be treated as untrusted output. Sanitization alone is not enough — attackers can craft prompts that evade filters, manipulate trusted library functions, and exploit model behaviors in ways that bypass traditional controls. An agent that generates and runs code on the fly creates a pathway where a crafted prompt escalates into remote code execution. That's not a bug. That's the architecture working as designed.

Krebs on Security ran a piece this month on autonomous AI assistants that proactively take actions without being prompted. The comments section was full of hackers (the good kind) asking the same question: "Who's watching the watchers?" Because your SIEM and EDR tools were built to detect anomalies in human behavior. An agent that runs code perfectly 10,000 times in sequence looks normal to these systems. But that agent might be executing an attacker's will.

OWASP saw this coming. They released a dedicated Top 10 for Agentic AI Applications — the #1 risk is Agent Goal Hijacking, where an attacker manipulates an agent's objectives through poisoned inputs. The agent can't tell the difference between legitimate instructions and malicious data. A single poisoned email, document, or web page can redirect your agent to exfiltrate data using its own legitimate access.

So here's the thing. You can write all the CLAUDE.md rules you want. You can put "never delete production data" in your system prompt. But those are requests, not guarantees. The model might ignore them. Prompt injection can override them. They're advisory — and advisory doesn't cut it when the agent has kubectl access to your prod cluster.

Hooks are the answer. They're the deterministic layer that sits between intent and execution. They don't ask the model nicely. They enforce. exit 2 = blocked, period. The model cannot bypass a hook. It's not running in the model's context — it's a plain shell script triggered by the system, outside the LLM entirely.

If you're an AppSec hacker who's been watching this AI agent gold rush with growing anxiety — this post is your field manual. We're going to cover what hooks are, how to wire them up, and the 5 production hooks that should be non-negotiable on every Claude Code deployment. The suits can keep their "digital workforce." We're going to make sure it can't burn the house down.

TL;DR

Claude Code hooks are user-defined scripts that fire at specific lifecycle events — before a tool runs, after it completes, when a session starts, or when Claude stops responding. They run outside the LLM as plain scripts, not prompts. exit 0 = allow. exit 2 = block. As of March 2026: 21 lifecycle events, 4 handler types (command, HTTP, prompt, agent), async execution, and JSON structured output. This post covers what they are, how to configure them, and 5 production hooks you should deploy today.

What Are Claude Code Hooks?

Hooks are shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific points in Claude Code's lifecycle. They run outside the LLM — plain scripts triggered by Claude's actions, not prompts interpreted by the model. Think of them as tripwires you set around your agent's execution path.

This distinction is what makes them powerful. Function calling extends what an AI can do. Hooks constrain what an AI does. The AI doesn't request a hook — the hook intercepts the AI. The model has zero say in whether the hook fires. It's not a polite suggestion in a system prompt that the model can "forget" when it's 50 messages deep. It's a shell script with exit 2. Deterministic. Unavoidable.

Claude Code execution
Event fires
Matcher evaluates
Hook executes

Your hook receives JSON context via stdin — session ID, working directory, tool name, tool input. It inspects, decides, and optionally returns a decision. exit 0 = allow. exit 2 = block. exit 1 = non-blocking warning (action still proceeds).

// HACKERS: READ THIS FIRST

Exit code 1 is NOT a security control. It only logs a warning — the action still goes through. Every security hook must use exit 2, or you've built a monitoring tool, not a gate. This is the rookie mistake I see everywhere. If your hook exits 1, the agent smiled at your warning and kept going.


The 21 Lifecycle Events

Here are the critical events. The ones you'll use 90% of the time are PreToolUse, PostToolUse, and Stop.

EventWhen It FiresBlocks?Use Case
SessionStartSession begins, resumes, clears, or compactsNOEnvironment setup, context injection
PreToolUseBefore any tool executionYES — deny/allow/escalateSecurity gates, input validation, command blocking
PostToolUseAfter tool completes successfullyYES — blockAuto-formatting, test runners, security scans
PostToolUseFailureAfter a tool failsYES — blockError handling, retry logic
PermissionRequestPermission dialog about to showYES — allow/denyAuto-approve safe ops, deny risky ones
UserPromptSubmitUser submits a promptYES — blockPrompt validation, injection detection
StopClaude finishes respondingYES — blockOutput validation, prevent premature stops
SubagentStopSubagent completesYES — blockSubagent task verification
SubagentStartSubagent startsNODB connection setup, agent-specific env
NotificationClaude sends a notificationNODesktop/Slack alerts, logging
PreCompactBefore compactionNOTranscript backup, context preservation
ConfigChangeConfig file changes during sessionYES — blockAudit logging, block unauthorized changes
SetupVia --init or --maintenanceNORepository setup and maintenance
// SUBAGENT RECURSION

Hooks fire for subagent actions too. If Claude spawns a subagent, your PreToolUse and PostToolUse hooks execute for every tool the subagent uses. Without recursive hook enforcement, a subagent could bypass your safety gates.


Configuration: Where Hooks Live

FileScopeCommit?
~/.claude/settings.jsonUser-wide (all projects)NO
.claude/settings.jsonProject-level (whole team)YES — COMMIT THIS
.claude/settings.local.jsonLocal overridesNO (gitignored)
// BEST PRACTICE

Put non-negotiable security gates in .claude/settings.json (project-level, committed to repo). Every team member gets the same guardrails automatically. Personal preferences go in .claude/settings.local.json.


The 4 Handler Types

1. Command Hooks — type: "command"

Shell scripts that receive JSON via stdin. The workhorse for most use cases.

{ "type": "command", "command": ".claude/hooks/block-rm.sh" }

2. HTTP Hooks — type: "http"

POST requests to an endpoint. Slack notifications, audit logging, webhook CI/CD triggers.

{ "type": "http", "url": "https://your-webhook.example.com/hook" }

3. Prompt Hooks — type: "prompt"

Send a prompt to a Claude model for single-turn semantic evaluation. Perfect for decisions regex can't handle — "does this edit touch authentication logic?"

{ "type": "prompt", "prompt": "Does this change modify auth logic? Input: $ARGUMENTS" }

4. Agent Hooks — type: "agent"

Spawn subagents with access to Read, Grep, Glob for deep codebase verification. The most powerful handler for complex multi-file security checks.


5 Production Hooks You Should Deploy Today

HOOK 01

Block Destructive Shell Commands

Event: PreToolUse | Matcher: Bash

Prevent rm -rf, DROP TABLE, chmod 777, and other commands that would make any hacker wince. Your AI agent doesn't need to nuke filesystems or wipe databases. If it tries, something has gone very wrong and you want that action dead before it executes.

// .claude/hooks/block-dangerous.sh

#!/bin/bash
# Read JSON from stdin
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Define dangerous patterns
DANGEROUS_PATTERNS=(
  "rm -rf"
  "rm -fr"
  "chmod 777"
  "DROP TABLE"
  "DROP DATABASE"
  "mkfs"
  "> /dev/sda"
  ":(){ :|:& };:"
)

for pattern in "${DANGEROUS_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qi "$pattern"; then
    echo "BLOCKED: Destructive command: $pattern" >&2
    jq -n '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "Blocked by security hook"
      }
    }'
    exit 2
  fi
done

exit 0

// settings.json config

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-dangerous.sh"
          }
        ]
      }
    ]
  }
}
HOOK 02

Auto-Format on Every File Write

Event: PostToolUse | Matcher: Write|Edit|MultiEdit

Every time Claude writes or edits a file, Prettier runs automatically. No prompt needed. No permission dialog. No exceptions.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\""
          }
        ]
      }
    ]
  }
}
HOOK 03

Block Access to Sensitive Files

Event: PreToolUse | Matcher: Read|Edit|Write|MultiEdit|Bash

Prevent Claude from reading or modifying .env, private keys, credentials, kubeconfig, and other sensitive files. This is Least Privilege 101 — the same principle every pentester exploits when they find an overprivileged service account. Don't let your AI agent become the next one.

// .claude/hooks/block-sensitive.sh

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.path // empty')

# Sensitive file patterns
SENSITIVE_PATTERNS=(
  "\.env$"      "\.env\."
  "secrets\."   "credentials"
  "\.pem$"      "\.key$"
  "id_rsa"      "id_ed25519"
  "\.pfx$"      "kubeconfig"
  "\.aws/credentials"
  "\.ssh/"      "vault\.json"
  "token\.json"
)

for pattern in "${SENSITIVE_PATTERNS[@]}"; do
  if echo "$FILE_PATH" | grep -qiE "$pattern"; then
    echo "BLOCKED: Sensitive file: $FILE_PATH" >&2
    jq -n '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "Sensitive file access blocked"
      }
    }'
    exit 2
  fi
done

exit 0
HOOK 04

Run Tests After Code Changes

Event: PostToolUse | Matcher: Write|Edit|MultiEdit

Automatically run your test suite on modified files. Catch regressions immediately instead of waiting for CI.

// .claude/hooks/run-tests.sh

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Only run tests for source files
if echo "$FILE_PATH" | grep -qE '\.(js|ts|py|jsx|tsx)$'; then
  # Skip test files to avoid loops
  if echo "$FILE_PATH" | grep -qE '(test|spec|__test__)'; then
    exit 0
  fi

  # Detect framework and run
  if [ -f "package.json" ]; then
    npm test --silent 2>&1 | tail -5
  elif [ -f "pytest.ini" ] || [ -f "pyproject.toml" ]; then
    python -m pytest --tb=short -q 2>&1 | tail -10
  fi
fi

exit 0
HOOK 05

Slack / Desktop Notification on Completion

Event: Stop | Matcher: (any)

When Claude finishes a long-running task, get notified immediately. Never forget about a background session again.

// .claude/hooks/notify-complete.sh

#!/bin/bash
INPUT=$(cat)
STOP_REASON=$(echo "$INPUT" | jq -r '.stop_reason // "completed"')

# macOS notification
osascript -e "display notification \"Claude: $STOP_REASON\" with title \"Claude Code\""

# Optional: Slack webhook
SLACK_WEBHOOK="${SLACK_WEBHOOK_URL}"
if [ -n "$SLACK_WEBHOOK" ]; then
  curl -s -X POST "$SLACK_WEBHOOK" \
    -H 'Content-Type: application/json' \
    -d "{\"text\": \"Claude Code finished: $STOP_REASON\"}" \
    > /dev/null 2>&1
fi

exit 0

Advanced: PreToolUse Input Modification

Starting in v2.0.10, PreToolUse hooks can modify tool inputs before execution — without blocking the action. You intercept, modify, and let execution proceed with corrected parameters. The modification is invisible to Claude.

Use cases: automatic dry-run flags on destructive commands, secret redaction, path correction to safe directories, commit message formatting enforcement.

// Example — Force dry-run on kubectl delete:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -q "kubectl delete" && \
   ! echo "$COMMAND" | grep -q "--dry-run"; then
  MODIFIED=$(echo "$COMMAND" | sed 's/kubectl delete/kubectl delete --dry-run=client/')
  jq -n --arg cmd "$MODIFIED" '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "allow",
      updatedInput: { command: $cmd }
    }
  }'
  exit 0
fi

exit 0

Advanced: Prompt Hooks for Semantic Security

Shell scripts handle pattern matching. But what about context-dependent decisions like "does this edit touch authentication logic?" or "does this query access PII columns?"

Prompt hooks delegate the decision to a lightweight Claude model:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write|MultiEdit",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "You are a security reviewer. Does this change modify auth, authz, or session management? If yes: {\"hookSpecificOutput\": {\"hookEventName\": \"PreToolUse\", \"permissionDecision\": \"escalate\", \"permissionDecisionReason\": \"Auth logic — human review required\"}}. If no: {}. Change: $ARGUMENTS"
          }
        ]
      }
    ]
  }
}

The escalate decision surfaces the action to the user for manual approval — perfect for high-risk changes that need a human in the loop.


Security Considerations

// 01: HOOKS RUN WITH YOUR USER PERMISSIONS

There is no sandbox. Your hooks execute with the same privileges as your shell. A malicious hook has full access to your filesystem, network, and credentials. Treat hook scripts like production code. Review them. Version control them. Don't curl | bash random hook repos from some stranger's GitHub. You wouldn't run an unvetted binary — don't run unvetted hooks either.

// 02: EXIT 2 VS EXIT 1 — THIS MATTERS

exit 2 = action is BLOCKED. Claude sees the rejection and suggests alternatives.
exit 1 = non-blocking warning. Action still proceeds.
Every security hook must use exit 2. Exit 1 = you're logging, not enforcing.

// 03: SUBAGENT RECURSION LOOPS

A UserPromptSubmit hook that spawns subagents can create infinite loops if those subagents trigger the same hook. Check for a subagent indicator in hook input before spawning. Scope hooks to top-level agent sessions only.

// 04: PERFORMANCE IS THE REAL CONSTRAINT

Each hook runs synchronously, adding execution time to every matched tool call. Threshold: if a PostToolUse hook adds >500ms to every file edit, the session becomes sluggish. Profile with time. Keep each under 200ms.

// 05: CLAUDE.MD = ADVISORY. HOOKS = ENFORCED.

"Never modify .env files" in CLAUDE.md = a polite request. The model might ignore it. A prompt injection will definitely override it.
A PreToolUse hook blocking .env access with exit 2 = a locked door. The model doesn't have the key.
Stop writing rules. Start writing hooks.


Getting Started Checklist

  • Start with two hooks: Destructive command blocker (Hook 01) and sensitive file gate (Hook 03). These prevent the most common AI agent mistakes with zero maintenance.
  • Commit to .claude/settings.json in your repo so the whole team shares the same guardrails automatically.
  • Use claude --debug when hooks don't fire as expected — shows exactly what's matching and executing.
  • Keep hooks fast — under 200ms each. Profile with time. Ten fast hooks outperform two slow ones.
  • Use $CLAUDE_PROJECT_DIR prefix for hook paths in settings.json for reliable path resolution.
  • Toggle verbose mode with Ctrl+O to see stdout/stderr from hooks in real-time during a session.

// References

  • Anthropic Official Docs — docs.anthropic.com/en/docs/claude-code/hooks
  • Claude Code Hooks Reference — code.claude.com/docs/en/hooks
  • GitHub: claude-code-hooks-mastery — github.com/disler/claude-code-hooks-mastery
  • 5 Production Hooks Tutorial — blakecrosley.com/blog/claude-code-hooks-tutorial
  • SmartScope Complete Guide — smartscope.blog/en/generative-ai/claude/claude-code-hooks-guide
  • PromptLayer Docs — blog.promptlayer.com/understanding-claude-code-hooks-documentation

03/05/2021

Solidity Smart Contract Upgradeability

Introduction 

This article is going to focus on Smart Contract upgradability, why this important and how can we achieve it. When dealing with Smart Contracts we need to be able to upgrade our system code. This is because if security critical bugs appear , we should be able to remediate the bugs. We would also want to enhance the code and add more features. Smart Contract upgradability is not as simple as upgrading a normal software due to the blockchain immutability.
 
As already mentioned by design, smart contracts are immutable. On the other hand, software quality heavily depends on the ability to upgrade and patch source code in order to produce iterative releases. Even though blockchain based software profits significantly from the technology’s immutability, still a certain degree of mutability is needed for bug fixing and potential product improvements.
 

Preparing for Upgrades   

In order to properly do the upgrade we should be focusing in the following aspects of the project:
  • Have money management strategies in place
  • Create a pause functionality 
  • Have paths to upgrades
    • Switching addresses
    • Switching Oracles
    • Proxy contracts 

The mentioned functionality is mandatory in order to properly maintain and do risk management on your system. The money management strategy has to do with were and how we hold the funds and the system data. The switch address is related to the proxy contract and the rest have to do with the flow paths we designed to upgrade the smart contracts [1]. 


Proxy Contract

The basic idea is using a proxy for upgrades. The first contract is a simple wrapper or "proxy" which users interact with directly and is in charge of forwarding transactions to and from the second contract, which contains the logic. The key concept to understand is that the logic contract can be replaced while the proxy, or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. The wrapper can thus point to a different logic implementation and in doing so, the software is "upgraded"


Note: This abstract proxy contract provides a fallback function that delegates all calls to another contract using the EVM instruction delegatecall. We refer to the second contract as the implementation behind the proxy, and it has to be specified by overriding the virtual _implementation function. Additionally, delegation to the implementation can be triggered manually through the _fallback function, or to a different contract through the _delegate function. 

The most immediate problem that proxies need to solve is how the proxy exposes the entire interface of the logic contract without requiring a one to one mapping of the entire logic contract’s interface. That would be difficult to maintain, prone to errors, and would make the interface itself not upgradeable. Hence, a dynamic forwarding mechanism is required [1].

Proxy Setup

Below we can see that the contract proxy has one to one relationship with all the logic contract proxy. An this is important in order to understand that this setup kind of breaks the immutability of the blockchain.
 

References:



14/02/2021

Threat Modeling Smart Contract Applications

INTRODUCTION 

Ethereum Smart Contracts and other complex blockchain programs are new, promising and highly experimental. Therefore, we should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed [1]. 

This article is going to focus on threat modeling of smart contract applications. Threat modelling is a process by which threats, such as absence of appropriate safeguards, can be identified, enumerated, and mitigation can be prioritized accordingly. The purpose of threat model is to provide contract applications defenders with a systematic analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker. 

Smart contract programming requires a different engineering mindset than we may be used to. The cost of failure can be high, and change can be difficult, making it in some ways more similar to hardware programming or financial services programming than web or mobile development. 

FORMAL VERIFICATION AND SMART CONTRACTS

At this point we should make clear that besides threat modeling, or as part of the threat modeling process, formal verification should also be mandatory. Formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. In a few words is crucial for the code to do what is supposed to do [2].

A very good project example, as far as formal verification is concerned is the Cardano cryptocurrency technology. Cardano is developing a technology using a provably correct security model that it provides a guaranteed limit of adversarial power [3]. Also Cardano is using Haskell as a programming language, which is a language that facilitates formal verification.

SMART CONTRACT ASSETS

In order to continue analyzing the information from the Smart Contract ecosystem will define what are assets in the context of this Smart Contract Applications. 

Assets are:
  • The Smart Contract function we require to protect. 
  • The Smart Contract data we require to protect.

THREAT ACTORS

This section is going to focus on the threat actors of the smart contract applications. A threat actor or malicious actor is a person or entity responsible for an event or incident that impacts, the safety or security of smart contract applications. In the context if this article, the term is used to describe individuals and groups that perform malicious acts. 

More specifically we are going to reference the following actors:
  • Nation State Actor with unlimited resources 
  • Organized Crime Actor with significant resources 
  • Insiders Actor with extensive knowledge of the system 
  • Hacktivists Actor with ideology as a motive and limited resources
  • Script Kiddies with limited knowledge of the technology and very few resources
  • Others Actors, such as accidental attacks
Note: From a threat intelligence perspective, threat actors are often categorized as either unintentional or intentional and either external or internal. Also threat agents should be primarily based on access e.g. external or internal actors etc. The likelihood of the threat is closely related to the attacker motive e.g. Nation state attacker has high level of motivation and Script Kiddies low level of motivation and therefor low likelihood. 

SMART CONTRACT THREAT ACTORS

In this section we are going to discuss the threat actors that are related only to Smart Contract Applications. Each technology has its own peculiarities, and blockhain technologies have their own. 

The actors that are related to Smart Contracts are two types:
  • Malicious Smart Contracts 
  • Humans interacting with Smart Contracts through DApps or directly.
Smart contracts can call functions of other contracts and are even able create and deploy other contracts (e.g. issuing coins). There are several use-cases for this behavior. 

A few use cases of interacting with other contracts are described below:
  • Use contracts as data stores
  • Use other contracts as libraries
In the context of this article an Actor interacting with a Smart Contract outside the blockchain is en external Actor and an Actor interacting with a smart contract inside the blockchain is an internal Actor. 

COMMON SMART CONTRACT ATTACKS

The following is a list of known attacks which we should be aware of, and defend against when writing smart contracts [4]. 
  • Reentrancy
    • Reentrancy on a Single Function
    • Cross-function Reentrancy
  • Timestamp Dependence
  • Integer Overflow and Underflow
  • DoS with (Unexpected) revert
  • DoS with Block Gas Limit
  • Gas Limit DoS on the Network via Block Stuffing
  • Insufficient gas griefing
  • Forcibly Sending Ether to a Contract
We are not going to explain each attack here. For more information please see the link [4].

ATTACK TREES

This section is going to focus the attack trees of the contract applications. Attack Trees provide a formal, methodical way of describing the security of systems, based on varying attacks. A tree structure is used represent attacks against a system, with the goal as the root node and different ways of achieving that goal as leaf nodes. 

The attack attributes assist in associating risk with an attack. An Attack Tree can include special knowledge or equipment that is needed, the time required to complete a step, and the physical and legal risks assumed by the attacker. The values in the Attack Tree could also be operational or development expenses. An Attack Tree supports design and requirement decisions. If an attack costs the perpetrator more than the benefit, that attack will most likely not occur. However, if there are easy attacks that may result in benefit, then those need a defense.

Below we can see a typical client browser attack tree:



ABUSE CASE DIAGRAMS

The relationships between the work products of a security engineering process can be hard to understand, even for persons with a strong technical background but little knowledge of security engineering. Market forces are driving software practitioners who are not security specialists to develop software that requires security features. When these practitioners develop software solutions without appropriate security-specific processes and models, they sometimes fail to produce effective solutions. Same thing happens with Smart Contract development, that is why abuse case diagrams should be used to model the security requirements of Smart Contract applications.

We will define an abuse case as a specification of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system.

Below we can see a simple use case diagram:


Below we can see a simple abuse case diagram with an external actor:



In the diagram above an external bad actor is manipulating the login function externally. This is a typical client browser attack e.g. the DApp application has an stored XSS and the attacker install a fake login page or the DApp does not handle correctly users private key etc. 

Below we can see another  simple abuse case diagram with an external actor:


Again in the diagram above an external bad actor is manipulating the the approve function externally. This is a typical client browser attack e.g. the DApp application has CSRF and the attacker exploits the vulnerability through a phishing attack etc. 

Below we can see a simple abuse case diagram with an internal actor:


Again in the diagram above an internal bad actor, this time, is manipulating the the approve function internally. This is an attack conducted internally from a malicious contract e.g. running a Reentrancy attack using the callback function e.t.c.

LAST WORDS

Before releasing any Smart Contract system make sure the system is pen-tested and the code is reviewed and there is in place a formal verification of the contract.

For code reviews make sure to:
  • Use a consistent code style
  • Avoid leaving commented code
  • Avoid unused code and unnecessary inheritance 
  • Use a fixed version of the Solidity compiler 
  • Analysis of GAS usage 
For pen-test make sure to:
  • Run a normal Web App pen-test for the web component of the DApp
  • Check how the DApp is interacting with the Smart Contract
Logical flow to follow would be:



TOOLS TO USE

Below there is a list of tools we can utilize to test our Smart Contract system:
  • Mythril :- Mythril is a security analysis tool for EVM bytecode. It detects security vulnerabilities in smart contracts built for Ethereum, Hedera, Quorum, Vechain, Roostock, Tron and other EVM-compatible blockchains.
  • Solhint :- Solhint is an open source project for linting Solidity code. This project provides both Security and Style Guide validations.
References: 


GitHub Actions as an Attacker's Playground

GitHub Actions as an Attacker's Playground — 2026 Edition CI/CD security • Supply chain • April 2026 ci-cd github-actions supply-c...