Тема: security
-
Мониторинг истечения TLS-сертификатов на всех узлах, а не только на основном сайте
Истёкший сертификат — это отказ с абсолютно предсказуемым моментом наступления; опрашивайте дату notAfter каждого реально обслуживаемого сертификата (веб, API, почта, внутренние панели, балансировщики нагрузки) снаружи, настраивайте оповещение с запасом времени, достаточным для ручного продления, и проверяйте не только листовой сертификат, но и промежуточные.
-
Как проверить, действительно ли TLS-соединение согласовало X25519MLKEM768
Отличайте наличие постквантовой возможности в установленном ПО от группы, выбранной в реальном TLS-соединении, с помощью сведений браузера, OpenSSL, curl и данных на стороне сервера.
-
Журналы аудита: что записывать, как сохранить их неизменность и кто может их читать
Журнал аудита отвечает на вопрос, кто что сделал с каким объектом, когда и с каким результатом; его ведёт само приложение по каждому значимому с точки зрения безопасности действию, хранят отдельно от отладочных логов, защищают от изменения, оперативно перенося в хранилище только для добавления или однократной записи, и читают только при протоколируемом, ограниченном доступе.
-
Устранение уязвимостей ядра Linux из KEV: сверяйте каждую CVE с пакетом дистрибутива и работающим ядром
Учитывайте пять эксплуатируемых уязвимостей ядра по отдельности. Используйте исправленные пакеты своего дистрибутива и подтверждайте либо загрузку исправленного ядра, либо явное покрытие через livepatch; мера для одной подсистемы не устраняет проблемы в остальных.
-
Секрет попал в коммит: почему удаления файла недостаточно и в каком порядке действовать
Учётные данные, отправленные в Git-репозиторий, сохраняются в истории, форках, клонах, кешах и журналах CI. Перезапись истории уменьшает дальнейшее раскрытие, но не отзывает копии, поэтому сначала отзовите и замените учётные данные, затем очистите историю и проверьте использование.
-
Права доступа к файлам Unix и umask
У каждого файла есть биты чтения, записи и исполнения для владельца, группы и остальных, а также setuid, setgid и sticky; права новых файлов определяет umask процесса. Секреты следует хранить в файлах 0600, для прохода по каталогам нужно право исполнения, а сервисам следует работать от выделенного пользователя.
-
System Integrity Protection и Signed System Volume: что они защищают и почему их не следует отключать
SIP запрещает даже root изменять защищённые системные пути или процессы; Signed System Volume криптографически опечатывает весь системный том и проверяет его при каждой загрузке. Вместе они объясняют, почему /usr/local доступен для записи, а /usr — нет, и почему отключение SIP не является допустимым исправлением ошибки прав доступа.
-
Лимиты запросов: защита сервиса и понятные сигналы клиенту
Ограничивайте запросы по проверяемому идентификатору — учётной записи или сетевому префиксу. Используйте атомарные счётчики в фиксированных или скользящих окнах, отвечайте 429 с Retry-After, разделяйте бюджеты чтения, записи и регистрации и публикуйте действующие лимиты.
-
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: привязка идентичности издателя к одобренным артефактам релиза
Trusted publishing через OIDC избавляет от хранения токенов публикации, но его безопасность по-прежнему зависит от разрешённого рабочего процесса. Отделяйте сборку от публикации, защищайте процедуру одобрения и сверяйте идентификационные данные артефакта, не принимая подтверждение происхождения за заключение об отсутствии вредоносного кода.
-
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.
-
Предотвращение межсайтового скриптинга с помощью кодирования при выводе
Экранируйте данные для конкретного контекста вставки: HTML-текста, атрибута, JavaScript, URL или CSS. Используйте шаблонизатор с экранированием по умолчанию, не собирайте HTML конкатенацией строк и дополняйте защиту строгой 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 года.
-
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.
-
Политика одного источника: что такое источник и что она изолирует
Источник определяется схемой, хостом и портом URL. Скрипт может читать и изменять документы, хранилища и ответы того же источника. Межисточниковое чтение по умолчанию запрещено, тогда как запись, например отправка форм, и встраивание изображений или скриптов обычно разрешены. CORS ослабляет ограничения чтения; защита от CSRF по-прежнему нужна.
-
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.
-
Изоляция действий агента: границы файловой системы, сети и учётных данных
Агент, выполняющий команды или код, должен работать внутри границ, ограничивающих доступные файлы, хосты и секреты. Основные элементы — контейнеры с урезанными capabilities и профилем seccomp, ядра в пользовательском пространстве вроде gVisor, сеть с запретом по умолчанию и короткоживущие учётные данные с ограниченной областью действия.
Машиночитаемо: JSON