Automating the boring parts, which is most of the job.
May 27, 2025
Security work generates a lot of repetitive tasks. Pull the same report every week. Check the same hundred hosts. Reformat the same export so a tool will accept it.
People who can script get through that in minutes and spend the rest of the day on work that needs judgment. People who cannot do it by hand, every time, forever.
Bash is on every Linux box you will ever touch. There is nothing to install and nothing to set up, which makes it the right first language for automation even though it is not a pleasant language.
The course starts with your first script and the shebang line, then variables, arguments, and exit codes. Exit codes matter more than beginners expect, because they are how scripts tell each other whether something worked.
Tests and conditionals, which in Bash have their own quirks around brackets and quoting that are worth learning properly rather than copying from a forum.
Then loops for doing the same thing to a list of hosts or files, and functions for the moment a script gets long enough that you are copying blocks around.
The practical target is a script you would actually run: something that takes a list, does something to each item, handles the case where an item fails, and tells you clearly what happened.
Bash is excellent at gluing programs together and moving text between them. It is bad at structured data, bad at error handling, and bad at anything that needs to be maintained by somebody else six months later.
The rule of thumb taught in the course is that once a script needs real data structures, talks to an API, or grows past a page or so, it should be Python.
The Python section starts at the beginning: variables, numbers, and text, then lists and dictionaries, then decisions and loops, then functions and real scripts.
Dictionaries get emphasis because almost every security data source you will meet is nested key and value data. Log events, API responses, and cloud configuration are all dictionaries wearing different clothes.
Reading and writing files. Handling errors with exceptions, so a script that hits one bad record does not fall over and lose the other four thousand.
Working with the system through os, pathlib, and subprocess, which is how you drive existing command line tools from Python and collect their output.
Regular expressions with the re module, which is the tool for pulling structure out of unstructured log text. Regular expressions are genuinely hard to read and worth learning anyway, because nothing else does the job as well.
Virtual environments and installing packages, so your projects do not fight each other. Then working with data through JSON and web APIs, which is how you get data out of a SIEM, a cloud provider, a ticketing system, or a threat intelligence feed.
The exercises are the tasks people actually automate. Parse a log file and count what matters. Query an API and turn the response into a report. Take a list of hosts and check something on each one. Reformat an export so a scanner will ingest it.
None of it is glamorous. All of it is the kind of thing that gets noticed at work, because you become the person who fixed the weekly task nobody liked. That is also useful proof of work for a portfolio.
AI assistants write plausible Bash and Python quickly, and for small scripts they are genuinely useful. They also produce code that runs and is wrong, which is a worse failure than code that does not run.
The habit the course teaches is to read every line before you run it, especially anything that deletes, overwrites, or connects somewhere. That applies double when the script will run as root. See AI in the SOC for the wider version of this problem.
Scripting is the multiplier on every other skill in security. It is covered inside the Specializing in Linux course rather than sold separately.