hugo@superuser:~/projects $ less index.md

Security rarely ranks first when launching a business. At the start, the focus is on getting the product ready to be launched. This means hardening often comes later—when workloads are already live and constraints have hardened alongside them.

Remediation usually arrives late, compounded by minimal security staffing, tight downtime tolerances, and constrained budgets where uptime is king. The reality is retrofitting controls while staying operational, enforcing policies without disrupting workflows, and building resilience where safeguards were never originally implemented.

Pushback from teams is another pain point, since the traditional “SSH to deploy” workflow is no longer possible. A real world example, hardening a public-facing server hosting a static website. Previously, the deployment pipeline used a standard user with shell access to the entire server. After hardening, that user is chrooted into the HTTP directory and has no TTY. The team relied on rsync, which doesn’t work without a TTY. rclone was proposed as an alternative, but the pushback was significant enough to escalate to upper management.

These experiences reinforced a core principle: security that breaks workflows gets bypassed. My job is harden systems in ways that preserved productivity—turning resistance into cooperation through technical alternatives and transparent communication.