The anomaly of cheap complexity

How does one design an electric motor? Would you attach a bathtub to it, simply because one was available? Would a bouquet of flowers help? A heap of rocks? No, you would use just those elements necessary to its purpose and make it no larger than needed – and you would incorporate safety factors. Function controls design.

– Prof. Bernardo de la Paz in The Moon Is A Harsh Mistress (Robert A. Heinlein)

Why are computer systems not very secure? Because they are composed of many complex layers. Why is it so even for simple applications like counting up votes or regulating temperature? It’s because today it’s easier and cheaper to build complex systems than it is to build simple ones.

Suppose you need a machine that does something not that complex, like a fridge. Complex general-purpose CPUs are cheap because of economies of scale and Moore’s law (ARM Cortex-M0 CPUs cost pennies). Software specializes a CPU that could do anything (universal computation) to become a device that does something.

Similarly a (huge and complex) general-purpose operating system is free, but a simpler, custom-designed, perhaps more secure OS would be very expensive to build.

Source: https://www.schneier.com/blog/archives/2022/08/security-and-cheap-complexity.html


Preventing git leaks

I track most of my code and prose via git and I store it on GitHub in public repos. I do it because I get reliable storage for free that I can access from any computer. And some of the repos might be helpful to others. Also it engages my hubris :-). It’s working nicely but sometimes I get a bad feeling when I push stuff. I’m worried that I might leak some sensitive information like passwords, API keys or tokens.

NOTE: don’t assume that committing secrets is ok when the repo is private. The files or their contents get copied and the platforms holding the repos get compromised.

Spotting secrets in new commits

The obvious solution is to think twice before committing and pushing data. But there are also some helpful tools, like gitleaks. It basically finds and reports secrets in the files you are about to commit. I want to run it whenever I commit something in any of my repos. These are the steps to make that happen:

  1. Install gitleaks.
  2. Add this to your ~/.gitconfig:
    hooksPath = ~/.git-global-hooks
  1. Create ~/.git-global-hooks/pre-commit:
# Detect secrets in a git repo using https://github.com/zricethezav/gitleaks

if [[ $SKIP == "gitleaks" ]]; then
    echo "skipping gitleaks checks ..."
    exit 0

set -xe

# Check uncommitted changes (parsing output of 'git diff') that had been 'git add'ed.
gitleaks protect --no-banner --staged

If, for some good reason, you want to skip gitleaks when committing: SKIP=gitleaks git commit -m "commit message"

You can also make gitleaks ignore a secret either by #gitleaks:allow inline comment next to the secret or by adding finding’s fingerprint to the .gitleaksignore file at the root of your repo. See docs for details.

Existing commits

The steps above will prevent you from committing secrets from now on. But you should also check existing commits because you might have committed a secret in the past. You can either do it on each commit by adding these lines to ~/.git-global-hooks/pre-commit:

# Check existing commits (parsing output of 'git log -p').
gitleaks detect --no-banner

But on bigger repos this might take several seconds every time you commit. To avoid this you can check all your historical commits in all your repos once. I used gh and runp to do it:

export GHORG=jreisinger # CHANGE ME
mkdir /tmp/$GHORG && cd /tmp/$GHORG
# clone all my (1000) repos in parallel
gh repo list $GHORG --source --limit 1000 | cut -f 1 | runp -p 'gh repo clone'
# check existing commits in all repos in parallel
ls | runp -p 'gitleaks detect --no-banner -s'

If runp exits with 0, all is good. Otherwise scroll up to review the output. To check a repo for committed leaks:

cd <repo>
gitleaks detect --no-banner -v

Gitleaks cheatsheet

# show secrets I'm about to commit (use --staged in pre-commit hook)
gitleaks protect -v

# show secrets that have been committed in the past
gitleaks detect -v

# show secrets no matter whether they are tracked by git
gitleaks detect --no-git -v


Let's have just fun

Some engineers, both junior and senior, have random approach to work as opposed to a systematic one. By random (or freestyle) approach I mean:

  • generating quick ideas without followup
  • kidnapping discussions with unrelated digressions
  • presenting ideas without putting an effort into thinking them over
  • making decisions without discussion
  • organizing useless meetings
  • hacking code without designing it
  • not using drawings when explaining concepts or designs
  • not tracking issues/tickets/projects
  • not documenting

By systematic (or disciplined) approach I mean the opposite.


I get that the random approach is easier (and more fun?) and that it tends to produce new ideas. But if you use it too much it will create unnecessary chaos and technical debt after some time. In other words it will increase technical and organizational (when embraced by managers) complexity without adding value. So you need some balance between freestyle and disciplined approach. To evaluate the balance look for the signs.

The signs of unhealthy level of technical complexity in software systems:

  • hard to use
  • unclear API and documentation
  • unclear design
  • difficult to find bugs
  • difficult to add new features
  • difficult to take over (or hand over)
  • operational problems and outages

The signs of unhealthy level of organizational complexity are:

  • meetings without agenda, conclusions and followup
  • people don’t show interest in the meetings
  • the same problems being discussed again and again
  • difficulty to schedule meetings, too many meetings
  • bureaucracy and rules that make no sense
  • non-existent or unclear team/company strategy and goals
  • non-existent or toxic team/company culture

(You can have unnecessary complexity also on personal level but I won’t discuss this here and now.)


I suspect that the main reason causing this problem is underestimating the importance of simplicity.

Simplicity is actually hard. To keep things simple you have to think about them, write your ideas down and review them several times. Consider what is the goal, what resources you have, what are the pros and cons of various ways to achieve the goal. You also have to discuss your ideas and listen to other people’s ideas. Once you have somehow clear ideas you have to communicate them well. Then you have to implement them (e.g. writing some code) and organize in accordance with them (via meetings, documentation, code structure). You have to be able to resist various pressures and temptations (you must be able to say NO to most things). And you have to do all this again and again. This requires time, energy, skill, motivation, patience and persistence. On the other hand it brings satisfaction.

In case your current team/company doesn’t want or is not able to do this (and you want or are) there are three options for you:

  • accept it and consider it a party instead of chaos :-)
  • get into a (management) position from which you can influence things
  • get into a company (which seems to be) heading in the right direction

The first option is the easiest one but not necessarily the right one. Of course you can and should always strive for simplicity on individual level. But you only have a certain amount of time, energy and patience.


My infosec career evaluation

I read Daniel Miessler’s article and liked it. So I tried to evaluate myself against it.

  • ✅ come from one of these backgrounds
    • system administration 👈
    • networking
    • development
  • ✅ have a good foundation in all these and a decent strength in one
    • system administration (Linux, LDAP, hardening, …)
    • networking (TCP/IP, switching, routing, protocols, …)
    • programming (concepts, scripting, OOP basics) 👈
  • ✅ have some relevant certifications (CCNA, CISSP, LPIC-2, CCENT, CKAD)
  • nurture your programming skills; you can build websites, tools, PoCs, …
  • ✅ stay up to date (twitter, email digests, …)
  • ✅ have a lab (AWS + home server)
  • ✅ be always working on (GitHub) projects
  • ✅ make contributions (on GitHub)
  • 🚫 practice with bug bounties (BugCrowd, HackerOne)
  • ✅ have a presence (web site, blog, Twitter)
  • ✅ network with others (interact on Twitter, go to conferences, …)
  • 🚫 respond to Call for Papers (CFP)
  • ✅ professionalism
    • dependability
    • speak concisely
    • tighten up you writing
    • learn to present
  • ✅ understand the business
  • ✅ have a passion
  • ✅ you’re in your 30’s, 40’s, or 50’s, and things are looking good :-)
  • 🤏 financial knowledge
  • ✅ management experience (managing people not only projects)
  • 🤏 extensive network (know a good percentage of the major players in infosec and business)
  • 🤏 dress/etiquette :-)
  • ✅ advanced education
  • 🚫 media savvy (trained to speak with the media about various topics)
  • 🤏 tech/business hybrid (be able to speak and work with devs and managers)
  • 🤏 creativity (able not only execute what you’re given but come up with new ideas and approaches to problems on a regular cadence)

Some of the above attributes are applicable only to certain career phases (junior, senior, team lead). Others are universal.