This post is a compilation of what I picked up while doing that.

Linux is Just the Kernel

Linux is just the kernel, the software that controls and manipulates the system's hardware. A Linux Distribution is the complete package of the Linux kernel + GUI + default apps + package managers + shell, etc. that makes up an OS.

The kernel is like the engine of a car. The distro or OS is the complete car with chassis, AC, interiors, body and everything else.

Raspberry Pi

A Raspberry Pi is just the hardware, a bare circuit board on a minimal basis and specs. It does not come with an OS, kernel or GUI. It comes with RAM, but no built-in storage.

The kernel, OS, files, data - everything exists on a micro-SD card. Pi Imager (a flashing tool) can be downloaded from the Pi official website onto the SD card. Then we just insert the card and turn it on.

Flashing - What It Really Means

Usually in an SD card or any storage device, there's a structure for the file system that determines where a piece of data exists or should be added to. There's like a menu of the data, a system that handles the data and searches for it too.

When we connect a pendrive to a laptop, the laptop sees the pendrive as just another drive with its own file system, ex: EXT4. When we try to paste data into the pendrive, the EXT4 system tells the pendrive hardware where to place those specific bytes.

With flashing, we don't copy-paste the image into the SD card at a location instructed by the filesystem. Instead we bypass the entire file system and place the ISO image data block-by-block directly on the hardware of the SD card. It replaces whatever existed in those blocks previously.

Now, the SD card doesn't contain the image data in one of its blocks. The SD card becomes the OS from the hardware level itself.

Some tools for flashing:

• Rufus - to repurpose an old Windows laptop into Linux

• BalenaEtcher - for macOS: https://etcher.balena.io/

• UTM - for virtualization on Mac (virtualizes ARM-native OS images, emulates other architectures using QEMU)

• VMware Fusion - also a good option for virtualization on macOS

Terminal vs Shell

Terminal is just the visual interface. It does not understand commands or anything.

Shell is the primary engine that processes commands, talks to the kernel, receives the output and conveys it to the terminal to display. When you connect to a remote host, the terminal belongs to your local Mac, but the shell belongs to the remote host.

Bash is the shell program used on Linux, for Mac it is Zsh.

The flow looks like this: terminal reflects the input I pass from the keyboard -> shell starts a process, parses it, expands it if needed -> kernel starts a child process -> kernel does the work, conveys the output and the child process exits -> shell process conveys output to terminal -> terminal displays the output.

Commands are just programs. cat is a program (which cat returns /usr/bin/cat). ls is a program too.

To check which shell I'm using: echo \(SHELL. What follows \) is a variable. We use caps when they are system variables or env variables set by the shell itself.

Everything is a File on Linux

This is one of those things that sounds abstract until you see it in practice.

Even processes are files. They may not be files that sit on the hard disk, but the kernel creates them on the fly just so I can read them using cat. The /proc folder is where the kernel presents process information as files. Similarly, every process gets its own directory of files that describe it. The kernel's process management is presented as files.

cat "something" > /dev/null - null is not really a file in /dev. It's just Linux's way of saying this is how you pass something into a black hole. But it looks like a file to any program, which makes it convenient to forward something into it.

When a program opens a network connection, the kernel creates a file descriptor that describes the connection. The program interacts with the file, and the corresponding actions are handled by the kernel. The program thinks it's "reading a file", but the kernel is actually pulling information from the network. The program thinks it's "writing to a file", but the kernel is actually sending data over the network.

Even pipes work this way. ps aux | grep ssh - ps aux just writes to a file and grep ssh just reads from a file. The pipe creates an anonymous file in between managing this process, but both commands think it's normal I/O.

Key Directories

• /home - user home directories

• /etc - system configuration files

• /var - variable data: logs, databases, mail

• /tmp - temporary files

• /usr - where installed software lives

• /bin - most command binaries

• /sbin - system administration binaries

• /opt - optional 3rd party software

• /dev - device files

• /proc - process and kernel information

Installing Software

Package managers vary by distro: apt for Debian-based (Ubuntu), apk for Alpine, pacman for Arch, dnf for RHEL/Fedora.

sudo apt update                          # update package repository list
sudo apt upgrade                         # upgrade all installed packages
apt search htop                          # search for a package
apt show htop                            # show info about a package
sudo apt install htop tree curl vim      # install packages with dependencies
sudo apt remove htop                     # remove package, keep config files
sudo apt purge htop                      # remove package including config files
apt list --installed                     # list all installed packages
apt list --installed | grep htop         # search within installed packages

When we install a program, it usually comes with 2 kinds of files: program files that carry the binaries to run it, and configuration files that customize the environment and variables to our requirements. System-wide config files are stored in /etc/. User-specific config files are usually dotfiles in the home directory, ex: .gitconfig.

Users, Groups & Permissions

whoami                    # current user
who                       # logged in users
id                        # user and group IDs
sudo adduser testuser     # create user
sudo deluser testuser     # delete user

File permissions follow the format: -rwxrwxrwx - file type, then owner, group, others. Read is 4, write is 2, execute is 1.

chmod 777 file-name       # or u+x, o+rw, etc.
chown user file           # change owner
chgrp group file          # change group
sudo -i                   # get root shell

Input, Output & Pipes

Three streams: standard input, standard output, standard error.

command > file.txt              # redirect output to file
command >> file.txt             # append instead of overwrite
wc -l < /etc/passwd            # redirect input from file
ls /nonexistant 2> /dev/null   # discard error output
ls /etc/ /nonexist &> all.txt  # redirect both stdout and stderr

Pipes send stdout of one command into stdin of another:

ls /etc | head -5
cat names.txt | sort | uniq -c
echo "HELLoo" | tr 'A-Z' 'a-z'
ls /etc/ | tee list.txt         # write to screen AND to a file

Processes

Processes have a PID, parent process (PPID), owner, and current state.

ps aux                     # list all processes
htop                       # real-time process viewer
kill -9 <PID>              # kill a process
pkill -f "python script.py" # kill by matching pattern
sleep 60 &                 # run in background
jobs                       # list background jobs
fg %1                      # bring job back to foreground

If a process is running in the foreground, Ctrl+Z pauses it, then bg takes it to the background.

systemd

systemd initializes the system at boot and manages services. It's a compiled binary on disk. Once the Linux kernel finishes initializing, it triggers systemd which becomes PID 1.

We use systemctl to interact with systemd, which handles starting, stopping or managing daemons. Unlike SysVinit which was the standard earlier, systemd runs the booting process in parallel. It manages the order of starting services, handles dependencies, mounts filesystems, sets up networking, manages user logins and so on.

Every service produces logs. journald captures those and can be queried through journalctl.

sudo systemctl start cron            # start a service (stop, restart, enable, disable)
journalctl --since "1 hour ago"      # query logs
pstree                               # visualize process tree

Networking

192.168.xxx.xxx always refers to a private internal network.

ip a                # view IP address, look for inet line on eth0
ip route            # view routing table, default points to WiFi router (gateway)
hostname            # view hostname
ping <ip>           # test connectivity
curl https://example.com    # download files / make HTTP requests
wget <url>                  # download files

Ports and Sockets

A port is just a number. A socket is a combination of IP address + port number + protocol (TCP/UDP). When a program wants to connect over the network, it asks the kernel to create a socket.

One port can have multiple sockets. For example, when we start sshd, it binds to port 22 and calls listen() which is a system call. This socket is now in LISTEN state. When a client connects, the listening socket creates a new socket with state ESTABLISHED for that connection, while the original one continues listening.

ss -tunlp           # see what ports are open and listening
ss -tun             # see active/established connections

/etc/hosts

Used to assign hostnames or shortcuts that we can easily remember, avoiding typing IP addresses every time. Can also be used to indirectly block websites by pointing, for example, www.facebook.com to the loopback address 127.0.0.1.

SSH

How it works behind the scenes:

1. Client runs ssh username@ip-address

2. SSH client creates TCP connection to server on port 22

3. TCP 3-way handshake

4. Diffie-Hellman key exchange

5. Authentication (password or key)

6. Encrypted channel established

7. Commands from our terminal run on the remote server

# Generate SSH keys
ssh-keygen -t ed25519

# Copy public key to server
ssh-copy-id user@ip-address

# If ssh-copy-id isn't available
cat ~/.ssh/id_ed25519.pub | ssh user@192.168.100.71 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Disable password authentication on server
vi /etc/ssh/sshd_config    # change PasswordAuthentication to no
sudo systemctl restart ssh

SSH config for shortcuts (~/.ssh/config):

Host linux
    HostName 192.168.1.12
    User admin
    IdentityFile ~/.ssh/id_ed25519

Now ssh linux just works.

Copy files with SCP:

scp file.txt admin@192.168.1.12:/home/admin              # local to remote
scp admin@192.168.1.12:/var/log/syslog ./                 # remote to local
scp -r directory/ admin@192.168.1.12:/home/admin          # copy directory

Tmux

Any process we execute on a remote server through SSH will break if we lose connection to the server. I generally used nohup if I knew it was going to take a lot of time, which I now realize was a pretty amateur approach. I discovered that tmux offers a much better way. It lets us run multiple terminal sessions inside one window and keeps them running even if we lose the SSH connection to the server.

Suppose we want to carry out multiple tasks on the same server, we'd normally use multiple SSH connections. Tmux handles that by allowing us to monitor multiple windows and panes in the same SSH session - watch logs in one terminal, edit files in another, and run scripts in a third. Without tmux, we would need 3 SSH connections.

sudo apt install tmux
tmux                              # start tmux
tmux new -s devops-lab            # create named session
tmux ls                           # list sessions
tmux attach -t devops-lab         # reattach to session
tmux kill-session -t devops-lab   # kill session

All tmux commands start with Ctrl+b:

Sessions: Ctrl+b d to detach

Windows (each window is a full terminal):

Panes (split each window into separate terminals):

Configuration & Customization

Dotfiles

Hidden files meant to manage configuration for the shell, editors, or other tools. Ex: .zshrc, .bashrc, .profile.

.profile is loaded once during SSH or boot. Contains env variables, PATH, etc.

.bashrc is loaded every time a new terminal opens because customizations like aliases, prompts, shell behaviors don't persist across terminals and cannot be inherited.

We usually put everything in .bashrc and then source it from .profile itself to maintain consistency.

Starship Prompt

Starship works across shells and VMs.

curl -sS https://starship.rs/install.sh | sh
echo 'eval "$(starship init bash)"' >> ~/.bashrc
source ~/.bashrc

Starship reads ~/.config/starship.toml, but it doesn't get created automatically:

mkdir -p ~/.config
vi ~/.config/starship.toml

Minimal configuration:

command_timeout = 1000
"$schema" = 'https://starship.rs/config-schema.json'
add_newline = true

[character]
success_symbol = '[➜](bold green)'

[package]
disabled = true

Explore more at: https://starship.rs/config/

Vim Configuration

cp /etc/vim/vimrc ~/.vimrc
# uncomment what's relevant

Tmux Configuration

vi ~/.tmux.conf

# Start window numbering at 1 (not 0)
set -g base-index 1
setw -g pane-base-index 1

# Enable mouse support
set -g mouse on

# Increase history limit
set -g history-limit 10000

# 256 color support
set -g default-terminal "tmux-256color"
set-option -sa terminal-overrides ',xterm-256color:RGB'

Book to read next: Unix and Linux System Administration Handbook

The Problem

Any process you run on a remote server through SSH is tied to that connection. Lose the connection, laptop sleeps, Wi-Fi drops, terminal closes, and your process dies with it. That deployment script you've been running for 30 minutes? Gone.

On top of that, if you need to do multiple things on the same server, watch logs, edit files, run scripts, you end up opening multiple SSH connections. That's multiple terminals, multiple authentication steps, and if your internet hiccups, all of them go down.

How Tmux Solves This

Tmux (Terminal Multiplexer) lets you run multiple terminal sessions inside a single SSH connection, and keeps them running even if you disconnect. You can detach, close your laptop, go grab coffee, come back, reattach, and everything is exactly where you left it.

It organizes your workspace into three layers:

• Sessions - the outermost container. Persists on the server until you kill it.

• Windows - like tabs within a session. Each one is a full-screen terminal.

• Panes - splits within a window. Run different things side by side.

Getting Started

Install tmux and start it:

sudo apt install tmux
tmux

You'll notice a green status bar at the bottom. You're now inside tmux. All tmux commands start with a prefix: Ctrl+b, followed by another key.

Session Management

tmux new -s devops-lab       # create a named session
tmux ls                      # list all sessions
tmux attach -t devops-lab    # reattach to a session
tmux kill-session -t devops-lab  # kill a session

Window Management

Each window is a full terminal, like having multiple tabs in one session, all through a single SSH connection.

Pane Management

Panes split a window into multiple terminals. This is where tmux really shines, monitor logs in one pane, edit config in another, and run commands in a third.

My Typical Workflow

When I SSH into a server for any real work, the first thing I do is:

tmux new -s work

Then I set up my workspace, split into panes, tail logs on one side, keep a shell on the other. If I need to step away, Ctrl+b d to detach. When I'm back, tmux attach -t work picks up right where I left off.

No more lost processes. No more juggling multiple SSH connections. Just one session that survives anything.

If you're working with remote servers in any capacity, make tmux part of your muscle memory. It's one of those tools that once you start using, you wonder how you ever worked without it.

I built VulnBank: a deliberately vulnerable Flask banking application, wired up to a Jenkins CI/CD pipeline with Semgrep scanning at every stage. The goal was simple — show what automated security scanning actually looks like in practice, what it catches, and where its limits are.

The full project is available here: https://github.com/PrakyathReddy/VulnBank-Semgrep

THE CORE IDEA

Functional correctness and security correctness are not the same thing.

A banking app can transfer money correctly, authenticate users correctly, and render pages correctly — and still be completely compromised by an attacker in under five minutes.

The demo makes this concrete. Every unit test passes. The app works exactly as intended. And yet Semgrep finds four blocking vulnerabilities the moment it scans the code.

That moment — tests green, Semgrep red, pipeline blocked — is the entire point.

WHAT'S IN THE APP

VulnBank is a minimal Flask app with six features, each containing an intentional vulnerability:

SQL Injection — Login Page

The login form concatenates user input directly into a SQL query string. An attacker can enter the username:

admin'--

and bypass the password check entirely. The double-dash comments out the rest of the query. No password needed. Logged in as admin.

This is one of the oldest and most common vulnerabilities in web applications. It's also one of the easiest to fix — parameterized queries solve it completely. But under deadline pressure, developers reach for f-strings, and this is what happens.

IDOR — Account Viewer

After logging in, your account is at /account/1. If you change that number to /account/2, you see someone else's account. /account/3 shows another. There is no ownership check anywhere in the code — the app verifies you are logged in, but never verifies the account belongs to you.

This is an Insecure Direct Object Reference (IDOR). It's consistently in the OWASP Top 10 because it's so common and so easy to miss in code review.

Command Injection — File Upload

The file upload feature runs a shell command to inspect the uploaded file. The filename comes from the user and goes directly into that shell command with shell=True. An attacker uploads a file named:

photo.jpg; cat /etc/passwd

The shell executes both commands. The server's password file is returned.

Hardcoded Secrets

The Flask secret key, admin credentials, and AWS keys are all hardcoded directly in app.py:

app.secret_key = "supersecretkey123" ADMIN_PASSWORD = "admin123" AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"

Anyone with repository access has these credentials. In a public repo, that means everyone.

Weak Cryptography — Password Reset

Password reset tokens are generated using MD5 of the username. MD5 is cryptographically broken. The token for any user is deterministic and precomputable. An attacker who knows your username can generate your reset token without ever interacting with the server.

Vulnerable Dependencies

requirements.txt pins requests to version 2.18.0, which carries multiple known CVEs including credential exposure via HTTP redirects. The app also pins an old version of Flask with a known advisory.

THE JENKINS PIPELINE

The pipeline has five stages. Each one builds on the last:

Stage 1 — Checkout Jenkins pulls the latest code from the GitHub repository. Nothing runs until the code is local.

Stage 2 — Install Sets up a Python virtual environment, installs application dependencies, and installs Semgrep and pip-audit.

Stage 3 — Semgrep SAST Runs Semgrep against the application code with --config auto. Semgrep loads rules appropriate for the detected language (Python/Flask) and scans every file. This is where SQL injection, command injection, and NaN injection are caught.

Stage 4 — Semgrep Secrets Runs Semgrep with the p/secrets ruleset against the entire repository. Designed to catch hardcoded API keys, tokens, and credentials.

Stage 5 — SCA with pip-audit Runs pip-audit against requirements.txt. This stage reads every pinned dependency, queries vulnerability databases, and reports every known CVE. This is where the 17 vulnerabilities across four packages surface.

Stage 6 — Security Gate Evaluates whether any prior stage failed. If anything failed, the gate blocks deployment with a clear message. The deploy stage never runs.

WHAT SEMGREP ACTUALLY FOUND

Running 128 rules across 17 files, Semgrep reported four blocking findings:

Finding 1: SQL Injection (Django rule) File: app.py, Line 113 User input concatenated directly into a raw SQL query string.

Finding 2: SQL Injection (Flask-specific rule) File: app.py, Line 113 Same line, flagged by a Flask-specific rule as well. Two different rule authors caught the same issue independently — which adds confidence.

Finding 3: NaN Injection File: app.py, Line 175 User input passed directly into float(). An attacker can pass the string "nan" which Python will cast to float NaN, causing undefined comparison behavior downstream. This one was not intentionally planted — Semgrep found it anyway.

Finding 4: subprocess with shell=True File: app.py, Line 228 subprocess.run called with shell=True and user-controlled input. The command injection vulnerability.

Scan summary: 4 findings, 4 blocking, 128 rules run, 17 files scanned.

The command injection was caught. The SQL injection was caught twice. A bonus vulnerability nobody planted was found. The pipeline failed. Deploy was blocked.

What Semgrep Did Not Catch

Hardcoded secrets - the generic strings like "supersecretkey123" and "admin123" did not match any pattern in the p/secrets ruleset. Semgrep's secrets rules are designed around recognisable formats: AWS key patterns that start with AKIA, GitHub tokens that start with ghp_, JWTs, private keys. A generic password assignment doesn't trigger them.

This is not a bug — it's a design decision. Flagging every string assignment would create overwhelming noise. But it means generic hardcoded credentials require either a paid tier with more rules, or custom rules written for your specific codebase.

IDOR was not caught either. IDOR is a logic flaw, not a code pattern. Semgrep can't know that your business rules require an ownership check on every account query — only you know that. This is exactly the use case for custom rules, which the project also includes.

SCA: WHERE THE REAL NOISE IS

pip-audit found 17 vulnerabilities across four packages: flask, requests, idna, and urllib3. This is what happens when you pin old dependency versions and never update them.

The requests package alone at version 2.18.0 carries four separate CVEs with fix versions ranging from 2.20.0 to 2.32.4. urllib3 at 1.21.1 carries sixteen vulnerabilities.

This is typical of real codebases. The application code might be relatively clean. The 99% of the codebase you didn't write — the dependencies — is often carrying years of unpatched vulnerabilities.

The SCA stage failed, which triggered the security gate, which blocked the deploy. This is the correct behavior.

THE SECURITY GATE

The security gate is the stage that makes everything meaningful. Without it, findings are advisory. Developers can see them, acknowledge them, and deploy anyway.

With a security gate:

Stage "Security gate" skipped due to earlier failure(s) SECURITY GATE FAILED — deployment blocked. Fix all findings before merging. Finished: FAILURE

The gate makes security non-negotiable. It enforces the shift-left philosophy not through culture or process, but through automation. Vulnerable code simply cannot reach production.

WHAT THIS DEMONSTRATES

After building and running this project end to end, a few things became very concrete:

Passing tests are not a security signal. All unit tests in the project pass. The app is functionally correct. The security failures are invisible to functional testing.

Speed matters. Semgrep scanned 17 files with 128 rules and returned results in seconds. A developer gets this feedback while they still have context about the code they just wrote.

Tools have limits. Semgrep missed the hardcoded secrets because they're generic strings. It missed the IDOR because it's a logic flaw. No tool catches everything. Understanding what a tool misses is as important as understanding what it catches.

Custom rules fill the gaps. The project includes custom Semgrep rules for IDOR detection and Flask-specific secret patterns. These are rules no public ruleset would ever have — because they're specific to this codebase's patterns. This is where the real depth of Semgrep becomes apparent.

SCA is often noisier than SAST. Four packages, seventeen vulnerabilities. Most of them are in transitive dependencies — packages you didn't choose, pulled in by packages you did choose. Managing this noise, distinguishing reachable from unreachable vulnerabilities, is where SCA tooling is still maturing.

CONCEPTS EXPLAINED

If some of the terminology in this post was unfamiliar, here is a plain-language breakdown of the key concepts behind what Semgrep does and why it works.

SAST — Static Application Security Testing

SAST analyses source code without executing the program. It reads your code as a structure and looks for patterns that indicate vulnerabilities — both known ones and potential ones.

The attacks SAST catches are a specific class: ones that do not require modifying source code at all. They come entirely through inputs the app itself asks for. A customer with malicious intent provides something unexpected, and the app handles it unsafely.

SQL Injection is the classic example. When an app asks for your name to look up your account, most users type their name. A malicious user types something like ' OR '1'='1' -- instead. The app takes that input and builds a SQL query from it. The attacker's input breaks out of the data context and becomes part of the query itself — extending it, modifying it, or bypassing it entirely. The impact ranges from reading data that should be private to corrupting the database to executing OS commands on the server. The fix is simple in principle: never treat input as an instruction. Use parameterized queries — curly-brace placeholders — which make it structurally impossible for input to escape the data context and become part of the command.

Command Injection works the same way at the OS level. The app accepts input and passes it to a shell command. A malicious user appends a semicolon and a second command. The shell runs both. The attacker now has the ability to run arbitrary commands on the backend server — delete files, exfiltrate data, install backdoors. The fix is to never pass user input directly to a shell. Use subprocess with a list of arguments and shell=False. Each argument is treated as a whole string and never parsed by the shell.

XSS — Cross Site Scripting — operates at the browser level rather than the server. When you log into a website, your browser downloads and executes that site's JavaScript. The site also gives you a cookie — a small token that identifies you so you don't have to log in on every page. JavaScript running on a page has access to those cookies, your session data, local storage, and the entire page content. If an attacker can inject a malicious script into a page — through an input field that isn't sanitized — your browser pulls that script down along with the legitimate code and executes it. The attacker's script can forward your cookies to their own server, log every keystroke, replace the entire page with a fake login form, or make network requests using your identity. The fix is to always treat user input as text, never as HTML. Before rendering any user-provided content back into a page, escape all HTML characters. The second line of defence is a Content Security Policy header — even if a script somehow gets in, the CSP header tells the browser only to execute scripts from verified, authorised sources.

How SAST Works Internally

To do any of this, SAST tools need to actually understand code rather than just search text. The pipeline looks like this:

Source code is parsed into an AST — an Abstract Syntax Tree. This is the source code broken apart into a tree of operators, assignments, function calls, and conditions that the tool can reason about structurally. Unlike raw text search, the AST represents what the code means, not just what it says.

Control flow analysis maps all the paths the code can take — branches, loops, function calls. Code rarely runs straight from top to bottom. It splits based on conditions, repeats in loops, jumps to functions and returns. SAST builds a map of every possible execution path.

Taint tracking then follows untrusted data — input from a user — along every one of those paths. The data enters at a source (a form field, a URL parameter, a cookie). The tool traces every variable it touches, every function it passes through, every transformation applied to it. If it reaches a sink — a database query, a shell command, a rendered HTML page — without being sanitized first, that path is a vulnerability. The finding is reported with the exact file and line number where the taint reaches the sink.

SCA — Software Composition Analysis

Modern applications are mostly code other people wrote. Your dependencies — the packages in requirements.txt, package.json, pom.xml — can easily represent 99% of what's actually running. SCA is focused entirely on that layer.

SCA reads your manifest files, resolves the full dependency tree including transitive dependencies (packages your packages depend on), and checks every package and version against large databases of known vulnerabilities. Each known vulnerability has a CVE identifier, a severity score, affected versions, and a fixed version.

SCA tools also check license types across the dependency tree — a GPL-licensed package in a commercial product can create legal exposure that has nothing to do with security. And SCA tools generate SBOMs — Software Bills of Materials — a machine-readable inventory of every component in your software with its version, license, and source. When a critical CVE drops, an SBOM lets you query instantly whether your product is affected, rather than manually checking every codebase.

Secrets Scanning

Credentials, API keys, tokens, and private keys accidentally committed to source code are one of the most common causes of breaches. Secrets scanning detects these by pattern matching against known formats — AWS keys follow a specific pattern, GitHub tokens have a recognisable prefix, private keys have a standard header — and by entropy analysis, flagging strings that are long and random-looking enough to be a real credential.

The limitation, as this project discovered firsthand, is that generic strings like "admin123" or "supersecretkey123" don't match known patterns and have low entropy. They require custom rules written for your specific codebase.

Shift-Left

The software delivery lifecycle runs roughly: Design, Code, Build, Test, Staging, Release, Production. Traditionally, security checkpoints lived near the right end of that line — pre-production reviews, penetration testing before release, security audits on finished software.

The shift-left philosophy moves security as far left as possible — ideally to the moment a developer writes the code. The reasoning is economic as much as technical: a vulnerability caught while the developer is still writing the code takes minutes to fix. The same vulnerability caught in a pre-production audit takes days. Caught in production after an incident, it can take weeks and cost significantly more in remediation, reputation, and regulatory exposure.

Semgrep is built for the left side of that line. It runs in seconds, integrates into CI/CD pipelines, and surfaces findings as inline comments on pull requests while the developer still has context. Checkmarx, by contrast, is built more toward the middle and right — deep comprehensive scans run nightly or weekly, reviewed by dedicated security teams, used for compliance reporting and formal sign-off.

Neither replaces the other. Semgrep catches the majority of issues fast and cheaply. Deeper tools catch the subtle cross-file flows and complex logic that fast scanners miss. A mature security program uses both.

IDOR — Insecure Direct Object Reference

Think of it this way: you are authorised to borrow a book from the library. But the librarian doesn't check which book — they just let you in. You can now take any book, or all of them.

In web applications, this means the app checks that you are logged in but never checks whether the specific resource you are requesting belongs to you. Your account is at /account/1. An attacker changes the URL to /account/2 and sees someone else's account. The app authenticated the user correctly. It never authorised which data that user is allowed to see. The fix is a single additional condition in the database query — fetch this account only if it belongs to the currently authenticated user.

RUNNING IT YOURSELF

Everything is in the repository. You need Docker, Python 3, and a free Semgrep account.

git clone https://github.com/PrakyathReddy/VulnBank-Semgrep cd VulnBank-Semgrep pip install -r requirements.txt python app.py

The app runs on localhost:5000. Demo credentials are in the README.

For the Jenkins pipeline, the README includes the exact Docker commands to get Jenkins running and connected to the repo.

Full project: https://github.com/PrakyathReddy/VulnBank-Semgrep

CLOSING THOUGHT

Security tooling only works if developers trust it and act on it. A tool that takes two hours to scan and produces eight hundred findings will be ignored. A tool that takes thirty seconds, produces four precise findings with line numbers and fix suggestions, and blocks the build — that gets fixed.

The shift-left movement is not really about tools. It is about putting security feedback at the moment when a developer can most easily act on it: while they are still thinking about that code, before the PR is merged, before the deploy happens.

VulnBank makes that concrete. The code is bad, the tests pass, the pipeline catches it, the deploy is blocked. That sequence — visible, automated, fast — is what good security tooling looks like in practice.

Austin Kleon's Show Your Work changed the way I think about creative visibility. It's not a book about self-promotion — it's a book about generosity, connection, and the quiet discipline of sharing what you're learning. Here are the ideas that stuck with me the most.

You Don't Have to Be an Expert

There's a beautiful concept in the book called scenius — the idea that creativity doesn't happen in isolation. It happens in communities of people who are learning from each other, borrowing ideas, remixing, and building something none of them could have built alone. Nobody in the group needs to be a genius. The magic is in the exchange.

This is liberating. It means you don't have to wait until you've "arrived" to start contributing. Make a commitment to learn in public. Share your journey, not just your destination.

Share the Process, Not Just the Product

We're trained to present finished work. But people connect with process. When you share your sources of inspiration, the messy middle, the challenges you're working through — you become relatable. You become human. And that's far more compelling than a polished case study.

Think of it in three stages. Early on, talk about what's inspiring you and what you're exploring. In the middle, share your methods and progress. At the end, reflect on outcomes and lessons learned. This kind of ongoing narrative is worth more than any résumé, because it shows people what you're working on right now.

The Daily Practice

Here's the simple discipline: once a day, before bed, look through what you've documented and share something from it. It doesn't have to be groundbreaking. It just has to be consistent.

But before you hit publish, ask yourself two questions: So what? and Is this useful to my reader? If the answer to either is "not really," hold it back. Generosity isn't the same as oversharing.

Think in Flow and Stock

Not everything you share carries the same weight, and that's fine. Flow is the daily stream — updates, observations, small insights. It keeps you visible and in rhythm. Stock is the stuff that lasts — the post someone bookmarks, the essay that's still relevant two months later. The beautiful thing is that stock often evolves from flow. Today's quick observation can become next month's best piece.

Own Your Space

Platforms come and go. Remember Myspace? Buy a domain with your name on it and build there. LinkedIn, Instagram, and whatever comes next are rented land. Your own site is home.

Teach Everything You Know

This one is counterintuitive. Won't sharing your secrets help your competition? In practice, no. When you teach openly, people feel like they were part of your journey. They root for you. They trust you. Hoarding knowledge creates distance; sharing it builds community.

Tell Better Stories

Here's something worth sitting with: how people feel about your work depends entirely on the story you tell them about it. And how they feel about it determines its value. A story is a lens — it frames perception. Learn to tell good ones, and your work will speak louder.

Be a Member Before You're a Leader

Want people to listen to you? Start by listening to them. The best way to lead a community is to first be a genuinely great member of one. Be curious. Be generous. Be present.

And if you want followers, the recipe is deceptively simple: be someone worth following. Be interested in things, and you'll become interesting.

Find Your Tribe

The whole act of putting your work out there is really about discovery — finding the people who think the way you do, care about the things you care about, and are building in the same direction. Be thoughtful about where you look. The right room matters more than the biggest room.

Play the Long Game

As your work gets more visible, criticism will come. That's the deal. Toughen up, learn to roll with it, and resist the urge to overthink every negative comment.

Keep showing up. Collect emails. Help others freely. Share valuable things without expecting a return. You'll get what you want if you stick around long enough — just don't quit too early.

And when you finally feel like you've mastered something? When the learning slows down and the spark fades? That's not the end. That's your cue to move on, become a beginner again, and start the whole beautiful cycle over.

Inspired by Show Your Work! by Austin Kleon. If these ideas resonate, I'd highly recommend picking up the book — it's a short, energizing read that might just change how you think about sharing your craft.

The Core Problem

Most of us try to resolve cross-cultural friction by focusing on individuals. "Oh, that's just how Raj is," or "Sarah's always blunt like that." But culture operates at a level deeper than personality. It shapes how we perceive, think, and act — often without us realizing it. When we mistake cultural patterns for personal quirks, misunderstandings pile up fast.

Meyer's insight is simple but powerful: before you can work effectively across cultures, you need a framework to decode those differences. That framework is her eight-scale model.

The Eight Scales

Meyer maps cultural differences along eight dimensions, each a spectrum between two extremes:

1. Communicating — Low-context (explicit, literal) vs. High-context (implicit, layered with subtext)

2. Evaluating — Direct negative feedback vs. Indirect negative feedback

3. Persuading — Principles-first (build the theory, then conclude) vs. Applications-first (lead with the result)

4. Leading — Egalitarian vs. Hierarchical

5. Deciding — Consensual vs. Top-down

6. Trusting — Task-based (earned through competence) vs. Relationship-based (earned through personal bonds)

7. Disagreeing — Confrontational vs. Avoids confrontation

8. Scheduling — Linear-time (strict adherence to schedules) vs. Flexible-time

Here's an example of a culture map comparing Israel and Russia across all eight scales. Notice how two countries can diverge sharply on some dimensions while sitting close together on others:

Every culture lands somewhere on each of these scales. The key is that it's always relative. Indians might seem disorganized compared to the French, but to a German, the French seem just as chaotic. There are no absolutes — only positions relative to your own starting point.

Within any country, there's still a bell curve of individual variation. Culture gives you the center of that distribution, not a rigid rule:

Culture and personality go hand in hand. There's a range of behaviors considered "normal" within any culture, and these ranges can overlap across countries. The Dutch and British ranges on the feedback scale, for example, overlap in the middle — meaning some Brits are more direct than some Dutch:

Communicating: Say What You Mean (or Don't)

This scale hit home the hardest for me. Countries like India, China, Japan, and Indonesia are high-context cultures. We expect people to read between the lines, pick up on what's implied, and share a web of unspoken reference points.

The US and most Anglo-Saxon countries sit at the low-context end. Communication is explicit, literal, and direct. The burden of clarity falls on the speaker, not the listener. Americans try to eliminate any room for misinterpretation.

Here's how this plays out in practice: in high-context Iran, if someone offers you food, you refuse twice before accepting — even if you're starving. In the US, you just say yes.

Or consider what happens when an American finishes a presentation and asks, "Any questions?" An Indian audience will often say, "No, it's clear" — even when it isn't. To an American, that confirmation is taken at face value. Confusion follows.

What each side thinks of the other:

• A low-context person perceives a high-context person as secretive, evasive, or just bad at communicating clearly.

• A high-context person thinks a low-context person is patronizing — stating what should already be understood.

The practical takeaway for anyone from a high-context culture working with Westerners: be transparent, be specific, be explicit. Don't assume anything is implied. Recap key points. Put things in writing. And if you don't understand something, say so directly rather than hinting at it politely.

Multi-cultural teams need low-context processes. The more low-context a culture, the more it gravitates toward written objectives, org charts, performance appraisals, and documented expectations — everything spelled out on paper.

Evaluating: The Feedback Minefield

Americans wrap negative feedback in layers of positivity — the classic "three positives for every negative" approach. The French criticize passionately and rarely bother with praise. The Dutch are blunt and straightforward. The Japanese would never criticize someone openly, especially not in a group.

We need to learn to interpret feedback properly. The British are a special case — they chronically understate everything. This table is one of the most memorable parts of the book:

When a British manager says "quite good," they might mean "barely acceptable." Learning to decode these patterns can save you from serious misreads.

What makes this tricky is that it doesn't always align with the communicating scale. Americans are low-context communicators (explicit and clear) but indirect when delivering criticism. The French are higher-context in general communication, but devastatingly direct with negative feedback.

This two-by-two quadrant captures the full picture:

Countries in Quadrant D (high-context, indirect feedback) like Japan, China, and India require the most care — never give negative feedback in front of a group, always do it in private.

One important caution: don't try to overcorrect. If you're from an indirect culture, suddenly being blunt with a Dutch colleague can backfire. Adaptation should be gradual.

Persuading: Why vs. What

This one surprised me. When an American presents an idea, they lead with the recommendation and the expected impact. Get to the point. What should we do, and what happens if we do it?

A German audience wants the opposite. Show me the methodology. Walk me through the reasoning. Explain the parameters. The conclusion should come last, as the logical endpoint of a rigorous process.

Meyer frames this as principles-first (deductive) versus applications-first (inductive) reasoning:

• Principles-first: A causes B, B causes C, therefore A causes C. Spend 80% of your time on the theory, 20% applying it. Understanding why matters deeply. Build your argument logically before concluding.

• Applications-first: Lead with the result. Spend 80% on practical application, 20% on underlying theory. How matters more than why. Shorter is sweeter.

Asian cultures add another layer entirely: holistic thinking. Where Westerners tend to zoom in on the most important element (micro to macro), Asians often zoom out — looking at relationships, interconnections, and how a task fits within the broader picture (macro to micro).

Leading: Egalitarian vs. Hierarchical

In egalitarian cultures (Denmark, Netherlands, Sweden), the boss is a facilitator among equals. Organizational structures are flat, and communication routinely skips hierarchical lines.

In hierarchical cultures (Japan, Korea, India, China), status matters. The best boss is a strong director who leads from the front. Organizational structures are multilayered and fixed, and communication follows set hierarchical lines.

In hierarchical cultures, leaders act like guardians who take care of their employees, and in return, employees are loyal and obedient. The burden of responsibility exists in both directions.

Deciding: Consensual vs. Top-Down

Here's where the model gets counterintuitive. You might assume egalitarian cultures make decisions by consensus and hierarchical cultures use top-down decision-making. Not necessarily.

American workplaces are relatively egalitarian — first names, open-door policies, casual dress. But decisions are often made quickly by individuals in charge, and those decisions are understood to be flexible and revisable. Speed matters more than buy-in. Meyer calls this "small-d" decision-making:

Germany is more hierarchical in its leadership style, but intensely consensus-driven when making decisions. Teams spend significant time discussing, debating, and aligning. But once a decision is made, it's final. No revisiting, no course corrections mid-stream. This is "big-D" Decision-making:

Japan takes this to an extreme: the most hierarchical leadership style in Meyer's model, combined with the deepest commitment to consensus. Through the ringi system, consensus builds from the bottom up — engineers agree, then low-level managers, then senior managers — until by the time a decision reaches the C-suite, it's essentially already been made. This is why it's nearly impossible to sway a Japanese decision once it reaches the top.

Trusting: Peaches and Coconuts

Meyer draws a memorable distinction between two types of trust: cognitive (based on competence and reliability — from the head) and affective (based on personal connection and warmth — from the heart).

Americans keep these sharply separated. They're friendly from the first handshake — warm, open, generous with smiles. But that friendliness isn't friendship. Meyer calls this a peach culture: soft and inviting on the outside, but hit a hard pit before long. They tend to put their best self forward and be careful not to reveal vulnerabilities — which can come across as performative or fake.

Many European cultures are the opposite — coconut cultures. The exterior is formal, even cold. But once you crack through, the relationships run deep and genuine.

The practical lesson: in relationship-based cultures, you socialize before getting down to business. When you move from the office to the pub, drop your professional guard. Be real, be vulnerable. Being guarded outside of work reads as inauthentic — and inauthenticity kills trust.

In many relationship-based cultures, the relationship is the contract.

Disagreeing: Debate vs. Face

The French love a good argument. They'll debate passionately, even aggressively, and then go to lunch together as if nothing happened. Disagreement is intellectual, not personal.

In much of Asia, the calculus is different. Protecting someone's face — their dignity and public standing — often matters more than being right. Open confrontation risks embarrassment, and embarrassment damages relationships. In non-confrontational cultures, attacking an opinion is seen as attacking the person.

An important nuance: confrontational doesn't necessarily mean emotionally expressive. Germans and Dutch are highly confrontational but emotionally restrained. Israelis and French are both confrontational and emotionally expressive. Meanwhile, countries like India and Saudi Arabia avoid confrontation but are still quite emotionally expressive:

This creates very different meeting cultures:

• American: Debate during the meeting itself and come to a decision.

• French: Discuss and debate various viewpoints — the meeting is for exploring ideas.

• Japanese/Chinese: The real discussion happens before the meeting, in side conversations and informal check-ins. The meeting itself is largely ceremonial — a space to formalize what's already been agreed upon.

Useful language tips: in confrontational cultures, use upgraders (totally, absolutely, completely). In non-confrontational cultures, use downgraders (sort of, kind of, partly, perhaps).

Scheduling: Linear-Time vs. Flexible-Time

In linear-time cultures (Germany, Japan, Switzerland), project steps are approached sequentially — one task at a time, no interruptions, strict adherence to deadlines. Punctuality and organization are paramount.

In flexible-time cultures (India, Nigeria, Saudi Arabia), things are more fluid. Multiple tasks are handled simultaneously, interruptions are accepted, and adaptability is valued over rigid planning.

Putting It All Together

Here's a culture map comparing four countries across all eight scales. Notice how each country has a unique signature — and how two countries might be close on one dimension but far apart on another:

What I'm Taking Away

Reading The Culture Map didn't give me a cheat sheet for every cross-cultural interaction. What it gave me was something more useful: a framework for noticing. Instead of attributing someone's behavior to their personality or assuming bad intent, I now ask myself where their culture might sit on these eight scales — and how that compares to my own defaults.

A few principles I'm trying to internalize:

Differences are relative, not absolute. Don't label a culture as "direct" or "hierarchical" in isolation — only as more or less so compared to your own.

Adaptation should be gradual. Overcorrecting or mimicking another culture can backfire spectacularly. Move slowly.

Multi-cultural teams need low-context processes. When in doubt, be more explicit, put more in writing, and assume less shared context.

Sometimes understanding is enough. Just recognizing that a behavior is cultural — that it's different, not wrong — can prevent a misunderstanding from becoming a conflict.

Style-switching across these dimensions is, as Meyer puts it, an essential skill for today's global worker. It's not about losing your cultural identity. It's about expanding your range.

Based on my notes from The Culture Map by Erin Meyer.

If you've ever read an amazing book or taken a course, only to completely forget the details a month later, you know this pain. As Tiago Forte puts it: The mind is for having ideas, not for storing them.

To fix this, I recently took a course by Mischa van den Berg, which inspired me to dive into three foundational books: The PARA Method and Building a Second Brain by Tiago Forte, and How to Take Smart Notes by Sönke Ahrens.

By combining the philosophies from these authors, I'm building a system to achieve super clarity of mind and ensure I never lose a good idea again. Here is how my new system works.

1. The CODE Framework: Managing the Flow (Credit: Building a Second Brain)

Tiago Forte introduces the CODE methodology to prevent digital hoarding and make your notes actually useful.

• Capture: Keep what resonates, but only capture the important, "noteworthy" kind of ones so they don't end up spamming your notes.

• Organize: Information should be organized based on how actionable it is, not what kind of information it is. Don't organize stuff based on where they came from, rather where they are going i.e. the outcomes they will help you realise. (Note: Forte's PARA method is the perfect folder structure for this step!).

• Distill: Distill your notes down to an essence so your future self can read one line and recall the concept. You can do this through progressive summarization: Captured notes -> Bolded Passages -> Highlighted passages -> Executive summary.

• Express: Share your knowledge, ideas, or presentations with the world.

2. The Zettelkasten Method: Taking Smart Notes (Credit: How to Take Smart Notes)

While CODE gives you the broad structure, Sönke Ahrens explains exactly how to write the notes using a "slip-box" or Zettelkasten method.

• Fleeting notes: Just write down what's in your head in the inbox folder, without worrying about how, where or why.

• Literature notes: While reading, be extremely selective, avoid copy-pasting, and write on your own to force an understanding.

• Permanent notes: Think how the new info relates to your existing notes (does it contradict, correct, or support them?). Write exactly as you were writing for someone else - use full sentences and try to be precise.

3. The Power of Connecting (Bottom-Up vs. Top-Down)

Both Ahrens and Forte emphasize building connections. The biggest mindset shift for me was moving from a top-down "planner" to a bottom-up "expert".

Usually, we plan an outline for a project and then look for data to support it, which makes us prone to confirmation bias. Instead, the bottom-up approach suggests we learn what interests us deeply, connect notes within our slip box, and let the project emerge naturally over time.

Our ability to remember things for the long term depend on how interconnected they are. When we bring diverse kinds of material in one place, we start identifying unusual connections and recognizing relationships, which make us creative.

Secret Weapons for Daily Work

I've also adopted a few incredible techniques from Forte's book to make executing my work completely frictionless:

• The Hemingway Bridge: Before calling it a day on something you are working on, take a moment to note down what you'll be doing for the next day, or time you plan to resume working. This creates a bridge for the next day which makes it very easy to resume.

• Archipelago of Ideas: Divergently gather all the sources, points, etc., that form the backbone of your essay, presentation or deliverable. Once you achieve a critical mass of ideas, decisively switch over to Convergence mode and link them together in an order that makes sense.

A good system of note taking will make me look well-prepared for any meeting I join or presentation I give. I highly recommend checking out Mischa's course and picking up these books if you want to stop relying on a fragile memory and start building a system that actually works.

I recently read The PARA Method by Tiago Forte, and it offered a solution that actually sticks. It isn't just about tidying up files; it's about organizing information for actionability.

Here is how the system works and the key habits I’m adopting to stop the digital clutter.

What is PARA?

The system breaks everything down into four primary categories based on how actionable the information is right now:

1. Projects: Short-term efforts with a deadline (e.g., "Complete Website Redesign").

2. Areas: Long-term responsibilities without a deadline (e.g., "Health," "Finances").

3. Resources: Topics or interests that might be useful in the future (e.g., "Web Design," "Cooking").

4. Archives: Inactive items from the other three categories.

The "Aha!" Moment: Projects vs. Areas

The biggest takeaway for me was distinguishing between Projects and Areas. We often feel overwhelmed because we treat ongoing responsibilities (Areas) like they are tasks we can "finish." But you never "finish" Health or Finance.

• Projects are concrete. They have boundaries and deadlines.

• Areas are the "hats you wear." They are the ongoing roles you maintain.

By breaking vague goals down into specific projects, we ensure our daily work is actually aligned with our long-term goals.

The Flow: Be Like Water

A common mistake is thinking a file lives in one folder forever. PARA is designed to be fluid. Information should flow like water in a river.

Priorities change. If a "Resource" becomes relevant to a current task, move it to "Projects." When a project is done, move it to "Archives." The system is not rigid; it moves from more actionable to less actionable depending on what you are doing right now.

3 Habits to Make it Stick

To keep the system from falling apart, Forte suggests three specific habits that I found really helpful:

1. Organize according to outcomes: Don't just file things away. Ask yourself, "Does this contribute to my current goals?".

2. Organize Just-in-Time: Don't create folders for things you might need. Wait until you actually have something to put in them. Don't add anything until you are ready to work on it.

3. Keep things informal: Don't over-engineer it with endless sub-folders. Some messiness is okay. As long as the Projects folder is clear, the rest can be a bit looser.

The Anti-Hoarding Mindset

Perhaps the hardest pill to swallow was this: Don't save everything. Saving every PDF or post "just in case" leads to digital hoarding that you will never revisit. PARA is meant to organize the life you have now, not the aspirational life you wish you had.

If you are feeling the weight of information overload or FOMO, I highly recommend giving this framework a shot. It helps you focus on one task at a time and actually finish what you start.

LinkedIn Post

I just set-up a 4-server k8s Homelab, and while my first choice was Docker for apps or Multi-pass/VMs for isolation, I went with LXD. Here’s why:

1. 𝗩𝗠'𝘀 are too "Expensive": Running 4 separate kernels wastes massive RAM.
Layers: Physical hardware ➡ host OS ➡ Hypervisor(VMware) ➡ Guest OS
2. 𝗗𝗼𝗰𝗸𝗲𝗿 is too "Thin": K8s expects to manage a node, not just a process. Docker-in-docker lacks the systemd init and robust networking required for a stable kubeadm environment.
Layers: Physical hardware ➡ host OS Kernel (shared) ➡ Docker Engine

The 𝗟𝗫𝗗 effect:
Layers: Physical hardware ➡ host OS Kernel (shared) ➡ LXD ➡ Full Guest OS
✅ Real Nodes: Each node has its own users, cron daemon, IP, storage, and systemd—essential for practicing kubeadm deployments.
✅ Instant Snapshots: I can snapshot the entire cluster before a risky kubectl upgrade and revert in seconds.
✅ Efficiency: I’m running a full 4-node cluster with less overhead than a single heavy Windows VM.

You can follow my journey through this repository: https://lnkd.in/g5U-VZ7t
prakyath.dev
#Kubernetes #K8s #LXD #CloudNative #Homelab #Ubuntu #DevOps #LinuxContainers

LinkedIn: https://www.linkedin.com/posts/prakyath-reddy-k_kubernetes-k8s-lxd-activity-7422489779583488000-f2gP?utm_source=share&utm_medium=member_desktop&rcm=ACoAACMLB3QBbJrDnMx5HudIT1V1XUhI362E08o