Utilities Tools
Miscellaneous developer utilities for everyday tasks.
Small utilities that save real time: scanning code for leaked secrets, masking personal data in JSON and CSV, visualizing cron schedules, and computing file checksums - the QA-adjacent chores that used to take multiple tools.
4 tools availableFour chores, four rules that keep the evidence honest
Each tool on this page is small, and each one sits on a rule worth knowing before you trust the output.
A secret in a fixture is still a secret
CWE-798, Use of Hard-coded Credentials, is defined in one line: "The product contains hard-coded credentials, such as a password or cryptographic key." Test repositories are where this weakness is easiest to create and hardest to notice, because the key is only "for staging" right up until the staging key opens something real. Scan before the branch is pushed, and rotate on discovery instead of quietly deleting the line.
Masking is not minimisation
Masking a column after exporting forty of them does not reduce what you hold. The UK GDPR's data-minimisation principle requires personal data to be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed", and NIST SP 800-188, De-Identifying Government Datasets, covers when a de-identification technique is strong enough for a given purpose. The order matters: decide the purpose, cut the fields, then mask what remains.
| Chore | Tool | The rule behind it |
|---|---|---|
| Scan for leaked secrets | Secret Scanner | CWE-798: hard-coded credentials, including a password or a cryptographic key |
| Mask personal data | Data Masker | GDPR Article 5(1)(c) data minimisation; NIST SP 800-188 for de-identification governance |
| Read a schedule before trusting it | Cron Calendar | systemd timers use wall-clock calendar expressions, subject to their accuracy setting |
| Trend quality numbers | QA Metrics Calculator | fix the denominator first - a defect count without its unit is not a metric |
Scheduling deserves the same scepticism. The systemd timer documentation warns that timers "do not necessarily expire at the precise time configured with these settings, as they are subject to the AccuracySec= setting" - so a nightly regression run has a window, and a test that asserts an exact start time will flake for a reason that has nothing to do with the product. Read the schedule in the Cron Calendar before you write that assertion, and keep the Secret Scanner, the Data Masker and the QA Metrics Calculator in the same pre-commit habit.
A crontab line is six fields, and the first five are ranges
POSIX describes the file before it describes the syntax: "a crontab entry is a text file consisting of lines of six fields each", and the first five are integer patterns with fixed bounds - "Minute [0,59] Hour [0,23] Day of the month [1,31] Month of the year [1,12] Day of the week ([0,6] with 0=Sunday)". Two consequences for a schedule you intend to assert on: 7 is not a portable way to write Sunday, and a month-end job set to day 31 silently skips the months that have 30. Render the schedule as text, then read the text back against the calendar you actually meant.
Two clocks then disagree about the same line. A wall-clock expression is evaluated against the zone the scheduler runs in, so a job set for 02:30 in a zone that springs forward at 02:00 either runs once or not at all that night. Keep the schedule in the site's zone, write the assertion against the rendered time, and let the Cron Calendar show the next five runs before the test claims a cadence.
Sources: CWE-798: Use of Hard-coded Credentials (MITRE); ICO guide to the data protection principles; NIST SP 800-188; systemd.timer; POSIX crontab.