🔄 Topic

Building a broad cybersecurity, networking, Linux, and developer-tooling glossary across my study vault, then linking every matching mention — and cleaning up the collateral damage that caused.

🎯 Goal

Turn scattered vocabulary across months of notes into a single, sourced reference layer, without corrupting the notes it touches.

🛠 What I Did

I scanned the vault for cybersecurity, Linux, shell, networking, web security, SOC, and adversary-behavior vocabulary, expanded a seed list into 348 terms, and generated one sourced note per term with a plain explanation, a why-it-matters line, and backlinks to where it appeared. Then I linked every matching mention across existing notes back into the glossary.

Main areas covered:

  • generating 349 files: 348 term notes plus one index
  • scanning 485 source files and updating 410 of them with new links
  • inserting 3,820 links across the vault
  • sourcing terms from NIST CSRC, MDN, OWASP, MITRE ATT&CK, RFCs, and official Git/GitHub Pages docs
  • validating every generated and modified file for broken or unbalanced links
  • grouping the 348 terms into five topic maps: Networking, Linux Privilege Escalation, Web Security, SOC Operations, and Developer Tooling

🔗 Key Cybersecurity Connections

Mass find-and-link automation across hundreds of files is exactly the kind of bulk change that needs a backup and a validation pass before you trust it — the same reasoning that applies to any bulk remediation script run against production data. I took a pre-link backup archive before running anything, which mattered.

🔍 Investigation Questions

  • Did the linker touch anything it shouldn’t have — frontmatter, code blocks, URLs, existing links?
  • What do the false positives look like, and why did they happen?
  • Is every generated link’s target actually present, or does it point at nothing?
  • Can the change be fully reverted from the backup if needed?

🚨 Detection Opportunities

Potential monitoring ideas:

  • bulk-edit jobs that modify hundreds of files without a prior backup
  • generated links whose target file doesn’t exist (broken reference)
  • automated text-matching that fires inside code blocks or raw syntax it shouldn’t touch
  • content restored from backup after an automated pass — a signal the pass needs tighter rules

Example:

project=cybersecurity-glossary
change_type=bulk_autolink_pass
risk_area=unintended_content_modification
triage=validate_then_diff_against_backup

🧭 MITRE ATT&CK Techniques

Not directly applicable to this task — this was a knowledge-base build, not adversary behavior. No mappings claimed here.

🗺 Visual Investigation Diagram

Scan vault for vocabulary
    ↓
Generate sourced term notes
    ↓
Autolink matching mentions
    ↓
Validate every link
    ↓
Restore false positives from backup

⚠ Challenges

Four notes came back damaged in a subtle way: raw terminal and Vim bracket syntax in lab session logs and cheat sheets looked enough like wiki-link syntax that the linker mangled it. Validation caught it, but it only caught it because I checked link balance file by file instead of trusting the summary counts.

📚 What I Learned

I learned that “0 missing targets” in a validation report is not the same as “nothing went wrong.” The real risk in bulk text automation isn’t missing links, it’s confidently correct-looking output that quietly broke something the validator wasn’t checking for.

➡ Next Steps

  • Add personal lab examples to high-value terms like SSH, SUID, IDOR, CSRF, and lateral movement
  • Consider additional topic maps: Identity and Access, Malware and Adversary Behavior, Detection Engineering, Cloud and Infrastructure
  • Keep the pre-link backup archive until I’m confident no other false positives exist

🧠 Reflection

This was a good reminder that automation validated against the wrong criteria is still unvalidated. I was checking “did links break,” not “did the linker rewrite something it should have left alone” — and both matter.

🧩 Lessons Learned

What worked

Taking a full backup before running a bulk change across 485 files, and skipping frontmatter, code blocks, URLs, and existing links by rule.

What broke

Four notes with raw terminal/Vim bracket syntax got misread as wiki-link syntax and needed manual restoration.

Why it broke

Text that looks like [[...]] syntax isn’t always a wiki link — sometimes it’s just what a terminal session or a Vim cheat sheet looks like.

Fix / takeaway

Validate for “unexpected changes,” not just “expected links present” — a clean link-count report can still hide corrupted content.

📈 Skill Progression Context

This supports my cybersecurity progression because running a large automated change safely — backup first, narrow rules, validate for the failure modes you didn’t anticipate — is the same operational discipline that separates a careful defender from one who trusts their own tooling too quickly.

😄 TL;DR

348 terms, 3,820 new links, and four notes that had to be rescued from a false-positive linker — the backup is what saved it.