guardia-ai/gitlab-componentСканер соответствия EU AI Act для конвейеров GitLab CI/CD — обнаруживает библиотеки ИИ/МО и публикует классификацию рисков в комментариях MR.
Чтобы упростить начало работы с GitLab, вот список рекомендуемых дальнейших шагов.
Уже профессионал? Просто отредактируйте этот README.md и сделайте его своим. Хотите упростить? Используйте шаблон внизу!
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
Используйте встроенную непрерывную интеграцию в GitLab.
Когда вы будете готовы сделать этот README своим, просто отредактируйте этот файл и используйте удобный шаблон ниже (или структурируйте его как угодно — это лишь отправная точка!). Спасибо makeareadme.com за этот шаблон.
Каждый проект уникален, поэтому подумайте, какие из этих разделов подходят для вашего. Разделы, используемые в шаблоне, являются рекомендациями для большинства проектов с открытым исходным кодом. Также имейте в виду, что хотя README может быть слишком длинным и подробным, лучше, чтобы он был слишком длинным, чем слишком коротким. Если вы считаете, что ваш README слишком длинный, рассмотрите возможность использования другой формы документации вместо удаления информации.
Выберите самодостаточное название для вашего проекта.
Дайте людям понять, что именно может делать ваш проект. Предоставьте контекст и добавьте ссылку на любые справки, которые могут быть незнакомы посетителям. Список функций или подраздел с предысторией также можно добавить сюда. Если существуют альтернативы вашему проекту, это хорошее место для перечисления отличительных факторов.
В некоторых README можно увидеть маленькие изображения, которые передают метаданные, например, проходят ли все тесты для проекта. Вы можете использовать Shields, чтобы добавить их в свой README. Многие сервисы также имеют инструкции по добавлению значка.
В зависимости от того, что вы создаете, может быть хорошей идеей включить скриншоты или даже видео (вы часто увидите GIF-изображения, а не настоящие видео). Такие инструменты, как ttygif, могут помочь, но ознакомьтесь с Asciinema для более сложного метода.
В рамках определенной экосистемы может быть общепринятый способ установки, например, с помощью Yarn, NuGet или Homebrew. Однако учтите, что читающий ваш README может быть новичком и нуждаться в более подробных инструкциях. Перечисление конкретных шагов помогает устранить неоднозначность и позволяет людям как можно быстрее начать использовать ваш проект. Если он работает только в определенном контексте, например, в определенной версии языка программирования или операционной системе, или имеет зависимости, которые необходимо устанавливать вручную, также добавьте подраздел Требования.
Используйте примеры щедро и показывайте ожидаемый результат, если это возможно. Полезно иметь встроенный самый маленький пример использования, который вы можете продемонстрировать, а также предоставлять ссылки на более сложные примеры, если они слишком длинные для разумного включения в README.
Сообщите людям, куда они могут обратиться за помощью. Это может быть любая комбинация трекера задач, чата, адреса электронной почты и т.д.
Если у вас есть идеи для будущих релизов, хорошей идеей будет перечислить их в README.
Укажите, открыты ли вы для вкладов и какие требования предъявляются к их принятию.
Для людей, желающих внести изменения в ваш проект, полезно иметь документацию о том, как начать. Возможно, есть сценарий, который они должны запустить, или некоторые переменные окружения, которые нужно установить. Сделайте эти шаги явными. Эти инструкции также могут быть полезны вам в будущем.
Вы также можете документировать команды для проверки кода или запуска тестов. Эти шаги помогают обеспечить высокое качество кода и снижают вероятность того, что изменения случайно что-то сломают. Наличие инструкций по запуску тестов особенно полезно, если требуется внешняя настройка, например, запуск сервера Selenium для тестирования в браузере.
Выразите признательность тем, кто внес вклад в проект.
Для проектов с открытым исходным кодом укажите, как он лицензирован.
Если у вас закончилась энергия или время на проект, поместите примечание в верхней части README о том, что разработка замедлилась или полностью остановлена. Кто-то может решить форкнуть ваш проект или вызваться стать мейнтейнером или владельцем, чтобы проект продолжал развиваться. Вы также можете сделать явный запрос на мейнтейнеров.
Помимо определения того, какие AI-библиотеки вы используете, сканер читает ваш исходный код и сообщает о конкретных обязательствах на конкретных строках:
| Правило | Что ищет |
|---|---|
GA-ART50-001 | Пользовательская конечная точка, обращающаяся к модели, без какого-либо уведомления в репозитории о том, что ответы созданы AI |
GA-ART12-001 | Модель, вызванная без вызова логирования, аудита или трассировки в области видимости |
Нарушения отображаются тремя способами: в виде комментария к запросу на слияние, в виде маркеров в diff запроса на слияние через отчет о качестве кода, и — с API-ключом — в виде записи на панели управления Guardia, которая отслеживает, что вы исправили и что внесли, коммит за коммитом.
include:
- component: gitlab.com/guardia-ai/gitlab-component/scan@main
inputs:
guardia_api_key: $GUARDIA_API_KEY # optional — keeps the record
code_analysis: 'true'
fail_on_findings: 'none'
Нарушения устраняются сами собой. Исправьте код — нашим патчем или своим — и следующий сканер просто перестанет о нем сообщать. Нажимать ничего не нужно.
Чтобы принять нарушение, укажите это в коде:
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
Это никогда не приводит к сбою сборки, и оно отображается на вашей панели управления как документированное принятие риска с автором из git blame — именно это хочет видеть аудитор.
В репозитории пятилетней давности будут нарушения, которые не совершал никто из текущей команды. Заморозьте их один раз, и только новая работа должна быть чистой:
guardia-scan . --write-baseline .guardia/baseline.json
Зафиксируйте этот файл. Нарушения, включенные в baseline, остаются видимыми в отчете и на панели управления — они просто никогда не приводят к неудачной проверке. Все, что введено после, приводит.
Каждый запуск может записать защищенную от взлома запись — что было найдено, в каком коммите, под какой версией набора правил и сколько юридической проверки прошло каждое правило на тот момент:
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # optional
Записи связаны хэшами, поэтому изменение прошлой записи нарушает все последующие записи. Без ключа подписи это доказывает внутреннюю согласованность, а не подлинность — запись сама сообщает об этом, а не оставляет вам догадываться.
Нарушения сообщают, что делает ваш код, и цитируют обязательство. Они не утверждают, что вы нарушаете закон — применяется ли обязательство, зависит от цели вашей системы и контекста развертывания, что ни один сканер кода не может определить. Правила цитируют Регламент (EU) 2024/1689 дословно, чтобы вы могли проверить обоснование самостоятельно.
Обнаружение работает полностью офлайн. Ваш исходный код никогда не покидает runner.