Welcome to the NZRT Wiki Podcast. Today we’re looking at Security Best Practices.

Security is everyone’s responsibility at NZRT, and today we’re walking through the core principles and practices that protect our code, credentials, and data — whether you’re a developer, a team lead, or just getting started.

Let’s start with the big ideas. At NZRT, security thinking is built around a handful of key concepts. First is the principle of least privilege — you only get the access you actually need to do your job, nothing more. Next is defense in depth, which means we don’t rely on just one security measure. We layer authentication, encryption, and logging so that if one control fails, others are still protecting you. Then there’s secret hygiene — never commit secrets to code, and rotate them regularly. We also insist on code review, audit trails, supply chain security for your dependencies and third-party code, and a clear incident response plan so you can act quickly when something goes wrong.

Now let’s talk about what that looks like day to day. NZRT has a security checklist covering five areas: repository setup, credentials and secrets, access control, code quality, and deployment.

Starting with your repository. Every repo should be private, with branch protection turned on for the main and develop branches. You need a CODEOWNERS file, a README with security instructions, and a gitignore that excludes things like dot-env files, secrets folders, and key files. And critically — no sensitive data should ever appear in your commit history.

On credentials and secrets: no API keys, tokens, or passwords go in the code. Full stop. Secrets live in GitHub Secrets, not in files. Database credentials go in a dot-env file, not in the example version that gets committed. You rotate credentials every three months, and you watch the audit log for unusual access.

For access control, team members get only the roles they need. Inactive users get removed. Admin access is limited to essential people. Two-factor authentication is on every account, SSH keys are registered and verified on GitHub, and personal access tokens are scoped as narrowly as possible.

On code quality: GitHub Actions runs on every pull request — linting, tests, and security scanning. You’re targeting test coverage above eighty percent. No hardcoded credentials. Dependencies are checked for vulnerabilities using Dependabot.

And for deployment: production uses SSH keys, not passwords. Deployments only go through GitHub Actions so they’re reproducible and audited. Status checks must pass before any merge, deployments are logged with timestamps and version numbers, and your rollback procedure is documented and tested.

Now for the secret management policy. NZRT tracks five categories of secrets. Think of it as a table with four columns — the type, some examples, how often you rotate, and where they’re stored. Database passwords like your MySQL credentials rotate quarterly and live in GitHub Secrets. API tokens — things like your Dolibarr or Slack tokens — also rotate quarterly and also go in GitHub Secrets. SSH deploy keys rotate every six months, again in GitHub Secrets. OAuth tokens like your GitHub token rotate quarterly. And SSL certificate private keys rotate annually and live in the server keystore.

What if a credential gets leaked? There’s a clear six-step response. First, immediately disable that credential at the source system. Second, use a tool called BFG Repo-Cleaner to scrub every occurrence from git history. Third, force-push the cleaned history. Fourth, rotate all related credentials — not just the one that leaked. Fifth, log the incident and write a postmortem. Sixth, notify any affected services.

Code review is your last line of defence before code ships. When you review a pull request, you’re checking that there are no secrets or hardcoded paths, that user input is validated, that output is properly escaped to prevent cross-site scripting, that database queries use parameterized statements, that authentication and authorization checks are in place, and that error messages don’t accidentally expose sensitive information.

And if a security issue is detected, follow seven steps: isolate the affected service or roll back the deployment, assess the scope and impact, notify the admin and relevant team leads, remediate and deploy a patch, verify the fix is working, document everything in a postmortem, and if user data was affected, communicate that to the right people.

Security isn’t a one-time setup — it’s an ongoing practice. Keep your credentials rotated, your reviews thorough, and your incident response sharp.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.