주제: security
-
메인 웹사이트뿐 아니라 모든 엔드포인트에서 TLS 인증서 만료 모니터링하기
만료된 인증서는 정확히 예측 가능한 시각에 발생하는 장애입니다. 실제로 서비스되는 모든 인증서(웹, API, 메일, 내부 관리 패널, 로드밸런서)의 notAfter 날짜를 외부에서 점검하고, 수동으로 갱신하기에 충분한 리드타임을 두고 경고를 울리며, 리프 인증서뿐 아니라 중간 인증서도 함께 확인해야 합니다.
-
TLS 연결에서 실제로 X25519MLKEM768이 협상되었는지 확인하기
브라우저 연결 정보, OpenSSL, curl, 서버 측 근거를 사용해 설치된 양자 내성 기능과 실제 TLS 연결에서 선택된 그룹을 구별합니다.
-
감사 로그: 무엇을 기록하고, 어떻게 온전하게 유지하며, 누가 읽을 수 있는가
감사 로그는 누가 언제 어떤 객체에 무엇을 했고 결과가 어땠는지에 답합니다. 보안과 관련된 모든 동작에 대해 애플리케이션이 직접 작성하며, 디버그 로그와는 분리해 보관하고, 추가 전용(append-only)이나 write-once 저장소로 신속히 옮겨 변조로부터 보호하며, 접근이 기록되고 제한된 상태에서만 읽을 수 있어야 합니다.
-
Linux 커널 KEV 조치: 배포판 패키지와 실행 중인 커널을 기준으로 각 CVE 검증하기
실제로 악용된 커널 취약점 다섯 가지를 각각 추적합니다. 배포판별 수정 패키지를 사용하고 부팅된 커널 또는 명시적인 livepatch 적용 범위를 확인해야 하며, 한 하위 시스템의 완화 조치로 나머지 취약점까지 해결되지는 않습니다.
-
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.
-
npm·PyPI 게시 신원을 승인된 릴리스 아티팩트에 연결하기
OIDC trusted publishing은 저장된 게시 토큰을 없애지만, 보안은 여전히 권한을 부여받은 워크플로에 달려 있습니다. 빌드와 게시를 분리하고 승인 절차를 보호하며, 출처 증명을 악성 코드 판정으로 받아들이는 대신 아티팩트의 신원을 검증해야 합니다.
-
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와 SD-WAN Manager: 수정 사항 확인과 침해 증거 보존
이메일 스캐너와 SD-WAN Manager의 조치 기록을 별도로 관리합니다. 실제로 설치된 수정 사항을 확인하고, 시스템 상태를 바꾸는 복구 작업 전에 증거를 보존하며, 제품별 조사 절차를 따릅니다.
-
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.
-
제조업체의 CRA 취약점 업무 절차 준비: 접수, 증거, 보고 기한 관리
취약점 접수와 구성요소 기록을 CRA 보고 판단에 연결하는 준비 절차를 제안합니다. 2026년에 이미 적용되는 보고 의무와 2027년 12월에 적용되는 더 폭넓은 취약점 처리 요구 사항을 구분합니다.
-
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.
기계 판독 가능: JSON