Topic: security
-
Monitoring TLS certificate expiry on every endpoint, not only the main website
An expired certificate is an outage with an exactly predictable time; probe the notAfter date of every certificate actually served (web, API, mail, internal panels, load balancers) from outside, alert with a lead time long enough to renew by hand, and check the intermediates as well as the leaf.
-
Checking whether a TLS connection actually negotiated X25519MLKEM768
Distinguish an installed post-quantum capability from the group selected on a real TLS connection, using browser details, OpenSSL, curl and server-side evidence.
-
Audit logs: what to record, how to keep them intact, and who may read them
An audit log answers who did what to which object, when and with what result; it is written by the application for every security-relevant action, kept separate from debug logs, protected against alteration by moving it promptly to append-only or write-once storage, and read only under recorded, restricted access.
-
Linux kernel KEV remediation: verify each CVE against the distribution package and running kernel
Track five exploited kernel flaws separately. Use distribution-specific package fixes and confirm either the booted kernel or explicit livepatch coverage; a mitigation for one subsystem does not close the others.
-
A secret was committed: why deleting the file is not enough and what the response order is
A credential pushed to a Git repository persists in history, forks, clones, caches and CI logs. Rewriting history reduces future exposure but cannot recall copies, so the first step is to revoke and rotate the credential, then clean the history, then check for use.
-
Unix file permissions and the umask
Each file has owner, group and other permission bits for read, write and execute, plus setuid, setgid and sticky bits; new files get permissions from the process umask. Secrets belong in 0600 files, directories need execute to be traversed, and services should run as a dedicated user.
-
System Integrity Protection and the Signed System Volume: what they protect, and why not to disable them
SIP restricts even root from modifying protected system paths or protected processes; the Signed System Volume cryptographically seals the entire system volume and checks it at every boot. Together they explain why /usr/local is writable but /usr is not, and why disabling SIP is not a legitimate fix for a permissions error.
-
Designing rate limits that protect the service and inform the client
Limit by the identity you can verify (account, network prefix), use atomic counters in fixed or sliding windows, answer 429 with Retry-After, keep separate budgets for reads, writes and registrations, and publish the effective limits.
-
Sudo policy as drop-in files in /etc/sudoers.d, checked with visudo -c
Adding a scoped rule as its own file under /etc/sudoers.d, validated with visudo before it takes effect, keeps sudo policy auditable and avoids a syntax error locking everyone out. This methodology also covers the risk of broad NOPASSWD rules and where sudo logs its decisions.
-
Binding npm and PyPI publishing identity to approved release artifacts
OIDC trusted publishing removes stored publishing tokens, but its security still depends on the authorized workflow. Separate building from publishing, protect approvals, and verify the artifact's identity instead of treating provenance as a malware verdict.
-
File upload service walk-through: direct-to-storage tickets, asynchronous scanning and quotas
A design walk-through for uploads that bypass the application servers: a ticket that reserves quota and returns a signed upload URL, a completion step that verifies the stored object, a scan worker that promotes or deletes it, lifecycle rules for abandoned uploads, and a status model that explains every stored object.
-
Preventing cross-site scripting by output encoding
Escape data for the exact context it is inserted into (HTML text, attribute, JavaScript, URL, CSS), use templating that escapes by default, never build HTML by string concatenation, and back it with a strict CSP.
-
Cisco Secure Email Gateway and SD-WAN Manager: verify fixes and preserve compromise evidence
Use separate remediation records for the email scanner and SD-WAN Manager. Verify actual installed fixes, preserve evidence before disruptive recovery, and follow the product-specific investigation path.
-
Short-link services with sequential identifiers receive more enumeration requests than services with random identifiers
Hypothesis: a URL shortener whose keys are a counter encoded in base62 lets anyone walk every link, whereas random fixed-length keys make most guesses miss; the proposal is that sequential services see a higher share of requests for existing keys from clients that never received the link, and that the share of 404 responses does not distinguish the two.
-
Preparing a manufacturer's CRA vulnerability workflow: intake, evidence and reporting clocks
A proposed preparation protocol connects vulnerability intake and component records to the CRA reporting decision. It separates the reporting duty already applicable in 2026 from the wider vulnerability handling requirements applicable in December 2027.
-
The Standard Webhooks spec versus Shopify's HMAC header and GitLab's shared-secret token
The Standard Webhooks specification defines webhook-id, webhook-timestamp and webhook-signature headers, a whsec_-prefixed base64 secret whose decoded bytes are the HMAC key, and a v1,<base64> signature over "{id}.{timestamp}.{payload}"; GitLab's signing tokens (GitLab 19.0, generally available in 19.1) implement exactly this. Shopify instead sends a base64 HMAC of the raw body in X-Shopify-Hmac-SHA256, and GitLab's older X-Gitlab-Token is a plain shared secret, not an HMAC at all.
-
Verifying installed RPM packages for tampering with rpm -V
rpm -V compares installed files against the checksums, permissions and ownership recorded when the package was installed, and its single-letter output codes say exactly what changed. This methodology covers reading that output and its limits as an integrity check.
-
The Same-Origin Policy: what an origin is and what it isolates
An origin is the scheme, host and port of a URL. Script may read and modify same-origin documents, storage and responses; cross-origin reads are blocked by default, while cross-origin writes such as form submissions and embedding such as images and scripts are generally allowed. CORS relaxes reads; CSRF defences are still needed.
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
Machine-readable: JSON