Проверка кода на безопасность

Находит в коде нарушения лучших практик безопасности для Python, JavaScript/TypeScript и Go, составляет отчёт и помогает исправить.

СкиллOpenAICodexApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Находит в коде нарушения лучших практик безопасности для Python, JavaScript/TypeScript и Go, составляет отчёт и помогает исправить.
Когда брать: Когда просят отчёт по безопасности проекта, рекомендации по защите или безопасный по умолчанию код.
Когда не брать: Для общего разбора кода, отладки и задач, не связанных с безопасностью, а также для языков вне Python, JavaScript/TypeScript и Go.
Пример запроса: Проверь мой проект на Python на уязвимости и составь отчёт по безопасности.
Нужно подключить: репозиторий с кодом
Работает лучше с: доступ в интернет

Как включить

Скачайте архив и распакуйте его.
Положите папку security-best-practices в ~/.agents/skills/.
Вызовите скилл командой $security-best-practices или найдите его через /skills.

Текст

---
name: "security-best-practices"
description: "Проводит проверки лучших практик безопасности для конкретных языков и фреймворков и предлагает улучшения. Включай, только если пользователь прямо просит рекомендации по лучшим практикам безопасности, проверку или отчёт по безопасности либо помощь в написании безопасного по умолчанию кода. Включай только для поддерживаемых языков (python, javascript/typescript, go). Не включай для общего разбора кода, отладки и задач, не связанных с безопасностью."
---

Лучшие практики безопасности

Обзор

Этот скилл описывает, как определить язык и фреймворки, используемые в текущем контексте, а затем загрузить из каталога references этого скилла сведения о лучших практиках безопасности для этого языка и (или) фреймворков.

Эти сведения, если они есть, можно использовать, чтобы писать новый безопасный по умолчанию код, пассивно находить серьёзные проблемы в существующем коде или (по просьбе пользователя) составлять отчёт об уязвимостях и предлагать исправления.

Рабочий процесс

Первый шаг этого скилла — определить ВСЕ языки и ВСЕ фреймворки, которые тебя просят использовать или которые уже есть в рамках проекта, над которым ты работаешь. Сосредоточься на главных базовых фреймворках. Часто нужно определить и языки с фреймворками для фронтенда, и для бэкенда.

Затем проверь каталог references этого скилла: есть ли там подходящая документация по языку и (или) фреймворкам. Обязательно прочитай ВСЕ справочные файлы, относящиеся к конкретному фреймворку или языку. Имена файлов имеют формат <language>-<framework>-<stack>-security.md. Проверь также, нет ли файла <language>-general-<stack>-security.md, который не зависит от используемого фреймворка.

Если работа идёт над веб-приложением с фронтендом и бэкендом, обязательно проверь справочные документы и для фронтенда, И для бэкенда!

Если тебя просят сделать веб-приложение и с фронтендом, и с бэкендом, но фреймворк фронтенда не указан, посмотри также javascript-general-web-frontend-security.md. Важно понимать, как защитить и фронтенд, и бэкенд.

Если в каталоге references этого скилла нет подходящих сведений, немного подумай о том, что тебе известно об этом языке, фреймворке и всех общеизвестных лучших практиках безопасности для них. Если не уверен, можешь поискать в интернете документацию по лучшим практикам безопасности.

Дальше скилл может работать несколькими способами.

Основной режим — просто использовать сведения, чтобы с этого момента писать безопасный по умолчанию код. Это полезно при старте нового проекта или при написании нового кода.

Второй режим — пассивно находить уязвимости, пока ты работаешь в проекте и пишешь код для пользователя. О критических или очень важных уязвимостях и серьёзных нарушениях рекомендаций по безопасности можно сообщать пользователю. Этот пассивный режим должен сосредоточиваться на уязвимостях с наибольшим влиянием и безопасных значениях по умолчанию.

Пользователь может попросить отчёт по безопасности или улучшить безопасность кодовой базы. В этом случае нужно составить полный отчёт, описывающий все способы, которыми проект не соблюдает рекомендации по лучшим практикам безопасности. Отчёт должен быть упорядочен по приоритету и содержать чёткие разделы по серьёзности и срочности. Затем предложи начать работу над исправлениями этих проблем. См. раздел «Исправления» ниже.

Дерево решений для рабочего процесса

Если язык или фреймворк неясен, изучи репозиторий, чтобы определить его, и перечисли свои доказательства.
Если в references/ есть подходящие рекомендации, загрузи только нужные файлы и следуй их инструкциям.
Если подходящих рекомендаций нет, подумай, известны ли тебе общеизвестные лучшие практики безопасности для выбранного языка и (или) фреймворков; но если просят составить отчёт, сообщи пользователю, что конкретных рекомендаций нет (отчёт всё равно можно составить, а критические уязвимости обнаружить наверняка)

Исключения

Хотя в этих справочных материалах собраны лучшие практики безопасности для языков и фреймворков, у заказчиков бывают случаи, когда эти практики нужно обойти или отменить. Обращай внимание на конкретные правила и инструкции в документации проекта и в файлах с промтами, которые могут требовать отменить некоторые лучшие практики. Если ты отменяешь лучшую практику, ты МОЖЕШЬ сообщить об этом пользователю, но не спорь с ним. Если лучшую практику безопасности нужно обойти или проигнорировать по причине, специфичной для проекта, можно также предложить добавить в проект документацию об этом, чтобы было ясно, почему практика не соблюдается, и в дальнейшем учитывать это исключение.

Формат отчёта

Составляя отчёт, запиши его как файл markdown с именем security_best_practices_report.md или в другое место, если его указал пользователь. Можешь спросить пользователя, куда записать отчёт.

В начале отчёта должно быть краткое резюме для руководства.

Отчёт должен быть чётко разделён на несколько разделов по серьёзности уязвимости. Отчёт должен сосредоточиваться на самых критических находках, так как они сильнее всего влияют на пользователя. Все находки нужно пометить числовым идентификатором, чтобы на них было проще ссылаться.

Для критических находок добавь одно предложение с описанием последствий.

Когда отчёт записан, сообщи о нём и пользователю напрямую, хотя можно менее подробно. Можешь предложить объяснить любую из находок или причины, стоящие за рекомендациями по лучшим практикам безопасности, если пользователь хочет узнать больше о каких-либо находках.

Важно: когда в отчёте ссылаешься на код, обязательно найди и укажи номера строк того кода, на который ссылаешься.

После записи файла отчёта кратко изложи находки пользователю.

Также сообщи пользователю, куда записан итоговый отчёт

Исправления

Если ты составил отчёт, дай пользователю прочитать его и попросить приступить к исправлениям.

Если ты пассивно нашёл критическую уязвимость, уведоми пользователя и спроси, хочет ли он, чтобы ты её исправил.

При внесении исправлений занимайся одной находкой за раз. В исправлениях должны быть краткие чёткие комментарии, поясняющие, что новый код основан на конкретной лучшей практике безопасности, и, возможно, очень короткая причина, почему поступать иначе опасно.

Всегда учитывай, повлияют ли изменения, которые ты хочешь внести, на работу кода пользователя. Подумай, не вызовут ли изменения регрессии в том, как проект работает сейчас. Часто небезопасный код используется ради других целей (поэтому небезопасный код и живёт так долго). Избегай поломки проекта пользователя: из-за этого он может не захотеть применять исправления безопасности в будущем. Лучше написать продуманное исправление, учитывающее остальной проект, чем сделать быструю небрежную правку.

Всегда следуй обычному порядку внесения изменений и коммитов, настроенному пользователем. Если делаешь коммиты в git, давай понятные сообщения коммитов, объясняющие, что это сделано ради соответствия лучшим практикам безопасности. Старайся не сваливать несколько несвязанных находок в один коммит.

Всегда следуй обычному порядку тестирования, настроенному пользователем (если он есть), чтобы убедиться, что твои изменения не приводят к регрессиям. Учитывай побочные эффекты второго порядка, которые могут иметь изменения, и сообщай о них пользователю до внесения изменений, если они есть.

Общие советы по безопасности

Ниже несколько советов по безопасному программированию, применимых почти к любому языку или фреймворку.

Не используй последовательные числовые идентификаторы как публичные идентификаторы ресурсов

Когда назначаешь идентификатор ресурсу, который затем будет доступен из интернета, не используй небольшие автоинкрементные идентификаторы. Используй вместо них более длинные случайные UUID4 или случайную шестнадцатеричную строку. Это не позволит пользователям узнать количество ресурсов и угадывать идентификаторы ресурсов.

Замечание о TLS

TLS важен для рабочих развёртываний, но большая часть разработки идёт без TLS или с TLS, который обеспечивает какой-нибудь внешний TLS-прокси. Поэтому будь очень осторожен и не сообщай об отсутствии TLS как о проблеме безопасности. Будь также очень осторожен с «защищёнными» (secure) файлами cookie. Их нужно задавать, только если приложение действительно работает через TLS. Если их задать в приложениях без TLS (например, при развёртывании для локальной разработки или тестирования), приложение сломается. Можно предусмотреть переменную окружения или другой флаг, переопределяющий установку secure, чтобы держать его выключенным до рабочего развёртывания с TLS. Кроме того, не рекомендуй HSTS. Его опасно использовать без полного понимания долгосрочных последствий (он может вызвать крупные сбои и блокировку пользователей), и в целом он не рекомендуется для проектов того масштаба, которые проверяет codex.

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/security-best-practices, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: "security-best-practices"
description: "Perform language and framework specific security best-practice reviews and suggest improvements. Trigger only when the user explicitly requests security best practices guidance, a security review/report, or secure-by-default coding help. Trigger only for supported languages (python, javascript/typescript, go). Do not trigger for general code review, debugging, or non-security tasks."
---

# Security Best Practices

## Overview

This skill provides a description of how to identify the language and frameworks used by the current context, and then to load information from this skill's references directory about the security best practices for this language and or frameworks.

This information, if present, can be used to write new secure by default code, or to passively detect major issues within existing code, or (if requested by the user) provide a vulnerability report and suggest fixes.

## Workflow

The initial step for this skill is to identify ALL languages and ALL frameworks which you are being asked to use or already exist in the scope of the project you are working in. Focus on the primary core frameworks. Often you will want to identify both frontend and backend languages and frameworks.

Then check this skill's references directory to see if there are any relevant documentation for the language and or frameworks. Make sure you read ALL reference files which relate to the specific framework or language. The format of the filenames is `<language>-<framework>-<stack>-security.md`. You should also check if there is a `<language>-general-<stack>-security.md` which is agnostic to the framework you may be using.

If working on a web application which includes a frontend and a backend, make sure you have checked for reference documents for BOTH the frontend and backend!

If you are asked to make a web app which will include both a frontend and backend, but the frontend framework is not specified, also check out `javascript-general-web-frontend-security.md`. It is important that you understand how to secure both the frontend and backend.

If no relevant information is available in the skill's references directory, think a little bit about what you know about the language, the framework, and all well known security best practices for it. If you are unsure you can try to search online for documentation on security best practices.

From there it can operate in a few ways.

1. The primary mode is to just use the information to write secure by default code from this point forward. This is useful for starting a new project or when writing new code.

2. The secondary mode is to passively detect vulnerabilities while working in the project and writing code for the user. Critical or very important vulnerabilities or major issues going against security guidance can be flagged and the user can be told about them. This passive mode should focus on the largest impact vulnerabilities and secure defaults.

3. The user can ask for a security report or to improve the security of the codebase. In this case a full report should be produced describe anyways the project fails to follow security best practices guidance. The report should be prioritized and have clear sections of severity and urgency. Then offer to start working on fixes for these issues. See #fixes below.

## Workflow Decision Tree

- If the language/framework is unclear, inspect the repo to determine it and list your evidence.
- If matching guidance exists in `references/`, load only the relevant files and follow their instructions.
- If no matching guidance exists, consider if you know any well known security best practices for the chosen language and or frameworks, but if asked to generate a report, let the user know that concrete guidance is not available (you can still generate the report or detect for sure critical vulnerabilities)

# Overrides

While these references contain the security best practices for languages and frameworks, customers may have cases where they need to bypass or override these practices. Pay attention to specific rules and instructions in the project's documentation and prompt files which may require you to override certain best practices. When overriding a best practice, you MAY report it to the user, but do not fight with them. If a security best practice needs to be bypassed / ignored for some project specific reason, you can also suggest to add documentation about this to the project so it is clear why the best practice is not being followed and to follow that bypass in the future.

# Report Format

When producing a report, you should write the report as a markdown file in `security_best_practices_report.md` or some other location if provided by the user. You can ask the user where they would like the report to be written to.

The report should have a short executive summary at the top.

The report should be clearly delineated into multiple sections based on severity of the vulnerability. The report should focus on the most critical findings as these have the highest impact for the user. All findings should be noted with an numeric ID to make them easier to reference.

For critical findings include a one sentence impact statement.

Once the report is written, also report it to the user directly, although you may be less verbose. You can offer to explain any of the findings or the reasons behind the security best practices guidance if the user wants more info on any findings.

Important: When referencing code in the report, make sure to find and include line numbers for the code you are referencing.

After you write the report file, summarize the findings to the user.

Also tell the user where the final report was written to

# Fixes

If you produced a report, let the user read the report and ask to begin performing fixes.

If you passively found a critical finding, notify the user and ask if they would like you to fix this finding.

When producing fixes, focus on fixing a single finding at a time. The fixes should have concise clear comments explaining that the new code is based on the specific security best practice, and perhaps a very short reason why it would be dangerous to not do it in this way.

Always consider if the changes you want to make will impact the functionality of the user's code. Consider if the changes may cause regressions with how the project works currently. It is often the case that insecure code is relied on for other reasons (and this is why insecure code lives on for so long). Avoid breaking the user's project as this may make them not want to apply security fixes in the future. It is better to write a well thought out, well informed by the rest of the project, fix, then a quick slapdash change.

Always follow any normal change or commit flow the user has configured. If making git commits, provide clear commit messages explaining this is to align with security best practices. Try to avoid bunching a number of unrelated findings into a single commit.

Always follow any normal testing flows the user has configured (if any) to confirm that your changes are not introducing regressions. Consider the second order impacts the changes may have and inform the user before making them if there are any.

# General Security Advice

Below is a few bits of secure coding advice that applies to almost any language or framework.

### Avoid Using Incrementing IDs for Public IDs of Resources

When assigning an ID for some resource, which will then be used by exposed to the internet, avoid using small auto-incrementing IDs. Use longer, random UUID4 or random hex string instead. This will prevent users from learning the quantity of a resource and being able to guess resource IDs.

### A note on TLS

While TLS is important for production deployments, most development work will be with TLS disabled or provided by some out-of-scope TLS proxy. Due to this, be very careful about not reporting lack of TLS as a security issue. Also be very careful around use of "secure" cookies. They should only be set if the application will actually be over TLS. If they are set on non-TLS applications (such as when deployed for local dev or testing), it will break the application. You can provide a env or other flag to override setting secure as a way to keep it off until on a TLS production deployment. Additionally avoid recommending HSTS. It is dangerous to use without full understanding of the lasting impacts (can cause major outages and user lockout) and it is not generally recommended for the scope of projects being reviewed by codex.

Источник: openai/skills / security-best-practices ↗. Ссылка проверена 2026-10-10.

---
name: "security-best-practices"
description: "Проводит проверки лучших практик безопасности для конкретных языков и фреймворков и предлагает улучшения. Включай, только если пользователь прямо просит рекомендации по лучшим практикам безопасности, проверку или отчёт по безопасности либо помощь в написании безопасного по умолчанию кода. Включай только для поддерживаемых языков (python, javascript/typescript, go). Не включай для общего разбора кода, отладки и задач, не связанных с безопасностью."
---

# Лучшие практики безопасности

## Обзор

Этот скилл описывает, как определить язык и фреймворки, используемые в текущем контексте, а затем загрузить из каталога references этого скилла сведения о лучших практиках безопасности для этого языка и (или) фреймворков.

Эти сведения, если они есть, можно использовать, чтобы писать новый безопасный по умолчанию код, пассивно находить серьёзные проблемы в существующем коде или (по просьбе пользователя) составлять отчёт об уязвимостях и предлагать исправления.

## Рабочий процесс

Первый шаг этого скилла — определить ВСЕ языки и ВСЕ фреймворки, которые тебя просят использовать или которые уже есть в рамках проекта, над которым ты работаешь. Сосредоточься на главных базовых фреймворках. Часто нужно определить и языки с фреймворками для фронтенда, и для бэкенда.

Затем проверь каталог references этого скилла: есть ли там подходящая документация по языку и (или) фреймворкам. Обязательно прочитай ВСЕ справочные файлы, относящиеся к конкретному фреймворку или языку. Имена файлов имеют формат `<language>-<framework>-<stack>-security.md`. Проверь также, нет ли файла `<language>-general-<stack>-security.md`, который не зависит от используемого фреймворка.

Если работа идёт над веб-приложением с фронтендом и бэкендом, обязательно проверь справочные документы и для фронтенда, И для бэкенда!

Если тебя просят сделать веб-приложение и с фронтендом, и с бэкендом, но фреймворк фронтенда не указан, посмотри также `javascript-general-web-frontend-security.md`. Важно понимать, как защитить и фронтенд, и бэкенд.

Если в каталоге references этого скилла нет подходящих сведений, немного подумай о том, что тебе известно об этом языке, фреймворке и всех общеизвестных лучших практиках безопасности для них. Если не уверен, можешь поискать в интернете документацию по лучшим практикам безопасности.

Дальше скилл может работать несколькими способами.

1. Основной режим — просто использовать сведения, чтобы с этого момента писать безопасный по умолчанию код. Это полезно при старте нового проекта или при написании нового кода.

2. Второй режим — пассивно находить уязвимости, пока ты работаешь в проекте и пишешь код для пользователя. О критических или очень важных уязвимостях и серьёзных нарушениях рекомендаций по безопасности можно сообщать пользователю. Этот пассивный режим должен сосредоточиваться на уязвимостях с наибольшим влиянием и безопасных значениях по умолчанию.

3. Пользователь может попросить отчёт по безопасности или улучшить безопасность кодовой базы. В этом случае нужно составить полный отчёт, описывающий все способы, которыми проект не соблюдает рекомендации по лучшим практикам безопасности. Отчёт должен быть упорядочен по приоритету и содержать чёткие разделы по серьёзности и срочности. Затем предложи начать работу над исправлениями этих проблем. См. раздел «Исправления» ниже.

## Дерево решений для рабочего процесса

- Если язык или фреймворк неясен, изучи репозиторий, чтобы определить его, и перечисли свои доказательства.
- Если в `references/` есть подходящие рекомендации, загрузи только нужные файлы и следуй их инструкциям.
- Если подходящих рекомендаций нет, подумай, известны ли тебе общеизвестные лучшие практики безопасности для выбранного языка и (или) фреймворков; но если просят составить отчёт, сообщи пользователю, что конкретных рекомендаций нет (отчёт всё равно можно составить, а критические уязвимости обнаружить наверняка)

# Исключения

Хотя в этих справочных материалах собраны лучшие практики безопасности для языков и фреймворков, у заказчиков бывают случаи, когда эти практики нужно обойти или отменить. Обращай внимание на конкретные правила и инструкции в документации проекта и в файлах с промтами, которые могут требовать отменить некоторые лучшие практики. Если ты отменяешь лучшую практику, ты МОЖЕШЬ сообщить об этом пользователю, но не спорь с ним. Если лучшую практику безопасности нужно обойти или проигнорировать по причине, специфичной для проекта, можно также предложить добавить в проект документацию об этом, чтобы было ясно, почему практика не соблюдается, и в дальнейшем учитывать это исключение.

# Формат отчёта

Составляя отчёт, запиши его как файл markdown с именем `security_best_practices_report.md` или в другое место, если его указал пользователь. Можешь спросить пользователя, куда записать отчёт.

В начале отчёта должно быть краткое резюме для руководства.

Отчёт должен быть чётко разделён на несколько разделов по серьёзности уязвимости. Отчёт должен сосредоточиваться на самых критических находках, так как они сильнее всего влияют на пользователя. Все находки нужно пометить числовым идентификатором, чтобы на них было проще ссылаться.

Для критических находок добавь одно предложение с описанием последствий.

Когда отчёт записан, сообщи о нём и пользователю напрямую, хотя можно менее подробно. Можешь предложить объяснить любую из находок или причины, стоящие за рекомендациями по лучшим практикам безопасности, если пользователь хочет узнать больше о каких-либо находках.

Важно: когда в отчёте ссылаешься на код, обязательно найди и укажи номера строк того кода, на который ссылаешься.

После записи файла отчёта кратко изложи находки пользователю.

Также сообщи пользователю, куда записан итоговый отчёт

# Исправления

Если ты составил отчёт, дай пользователю прочитать его и попросить приступить к исправлениям.

Если ты пассивно нашёл критическую уязвимость, уведоми пользователя и спроси, хочет ли он, чтобы ты её исправил.

При внесении исправлений занимайся одной находкой за раз. В исправлениях должны быть краткие чёткие комментарии, поясняющие, что новый код основан на конкретной лучшей практике безопасности, и, возможно, очень короткая причина, почему поступать иначе опасно.

Всегда учитывай, повлияют ли изменения, которые ты хочешь внести, на работу кода пользователя. Подумай, не вызовут ли изменения регрессии в том, как проект работает сейчас. Часто небезопасный код используется ради других целей (поэтому небезопасный код и живёт так долго). Избегай поломки проекта пользователя: из-за этого он может не захотеть применять исправления безопасности в будущем. Лучше написать продуманное исправление, учитывающее остальной проект, чем сделать быструю небрежную правку.

Всегда следуй обычному порядку внесения изменений и коммитов, настроенному пользователем. Если делаешь коммиты в git, давай понятные сообщения коммитов, объясняющие, что это сделано ради соответствия лучшим практикам безопасности. Старайся не сваливать несколько несвязанных находок в один коммит.

Всегда следуй обычному порядку тестирования, настроенному пользователем (если он есть), чтобы убедиться, что твои изменения не приводят к регрессиям. Учитывай побочные эффекты второго порядка, которые могут иметь изменения, и сообщай о них пользователю до внесения изменений, если они есть.

# Общие советы по безопасности

Ниже несколько советов по безопасному программированию, применимых почти к любому языку или фреймворку.

### Не используй последовательные числовые идентификаторы как публичные идентификаторы ресурсов

Когда назначаешь идентификатор ресурсу, который затем будет доступен из интернета, не используй небольшие автоинкрементные идентификаторы. Используй вместо них более длинные случайные UUID4 или случайную шестнадцатеричную строку. Это не позволит пользователям узнать количество ресурсов и угадывать идентификаторы ресурсов.

### Замечание о TLS

TLS важен для рабочих развёртываний, но большая часть разработки идёт без TLS или с TLS, который обеспечивает какой-нибудь внешний TLS-прокси. Поэтому будь очень осторожен и не сообщай об отсутствии TLS как о проблеме безопасности. Будь также очень осторожен с «защищёнными» (secure) файлами cookie. Их нужно задавать, только если приложение действительно работает через TLS. Если их задать в приложениях без TLS (например, при развёртывании для локальной разработки или тестирования), приложение сломается. Можно предусмотреть переменную окружения или другой флаг, переопределяющий установку secure, чтобы держать его выключенным до рабочего развёртывания с TLS. Кроме того, не рекомендуй HSTS. Его опасно использовать без полного понимания долгосрочных последствий (он может вызвать крупные сбои и блокировку пользователей), и в целом он не рекомендуется для проектов того масштаба, которые проверяет codex.

Перевод: iiuniversitet. Оригинал: https://github.com/openai/skills/tree/main/skills/.curated/security-best-practices, лицензия Apache-2.0. Изменения: перевод на русский язык.