Обсуждение критериев

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

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

Эта страница обсуждает набор лучших практик для проектов свободного и открытого ПО (Free/Libre and Open Source Software - FLOSS), разработанных для значка "Передовая практика Open Source Security Foundation (OpenSSF)". Проекты, которые следуют этим лучшим практикам, смогут добровольно самостоятельно сертифицироваться и показать, что они получили соответствующий значок. Проекты могут сделать это бесплатно, используя веб-приложение (BadgeApp), чтобы объяснить, как они соответствуют этим практикам и их подробным критериям.

Эти лучшие практики были созданы для:

1. поощрения проектов следовать лучшим практикам,
2. помощи новым проектам узнать, что это за практики, и
3. помощи пользователям узнать, какие проекты следуют лучшим практикам (чтобы пользователи могли предпочесть такие проекты).

Идиома "лучшие практики" означает "процедура или набор процедур, которые предпочтительны или считаются стандартными в организации, отрасли и т.д." (источник: Dictionary.com). Эти критерии - это то, что мы считаем широко "предпочтительным или считающимся стандартным" в более широком сообществе FLOSS.

Для получения дополнительной информации о том, как были разработаны эти критерии, см. сайт значка "Передовая практика OpenSSF" на GitHub.

Вы также можете посмотреть полные критерии.

Структура критериев

Критерии лучших практик разделены на три уровня:

• Passing фокусируется на лучших практиках, которым хорошо работающие проекты FLOSS обычно уже следуют. Получение значка passing - это достижение; в любой момент времени только около 10% проектов, стремящихся к значку, достигают уровня passing.
• Silver - это более строгий набор критериев, чем passing, но ожидается, что он достижим для небольших проектов и проектов одной организации.
• Gold - это еще более строгий набор критериев, чем silver, и включает критерии, которые недостижимы для небольших проектов или проектов одной организации.

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

Связь с другими проектами

Linux Foundation также спонсирует проект OpenChain, который определяет критерии для "высококачественной программы соответствия Free and Open Source Software (FOSS)". OpenChain фокусируется на том, как организации могут лучше всего использовать FLOSS и вносить вклад обратно в проекты FLOSS, в то время как значок OpenSSF Best Practices фокусируется на самих проектах FLOSS. Значок OpenSSF Best Practices и OpenChain работают вместе, чтобы помочь улучшить FLOSS и способы использования FLOSS.

Критерии автоматизации

В некоторых случаях мы автоматически тестируем и заполняем информацию, если проект следует стандартным соглашениям и размещен на сайте (например, GitHub) с хорошей поддержкой API.

Мы намерены улучшить эту автоматизацию в будущем. Улучшения автоматизации приветствуются!

Однако мы намеренно отдали приоритет тому, "что важно", даже если это не может быть экономически автоматизировано. Мы любим автоматизированные измерения, но не всё важное можно автоматизировать или автоматизировать экономически.

Изменения со временем

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

Отзывы очень приветствуются через сайт GitHub в виде задач или запросов на слияние. Также есть список рассылки для общего обсуждения.

Ключевые слова

Ключевые слова "MUST" (ДОЛЖЕН), "MUST NOT" (НЕ ДОЛЖЕН), "SHOULD" (СЛЕДУЕТ), "SHOULD NOT" (НЕ СЛЕДУЕТ) и "MAY" (МОЖЕТ) в этом документе следует интерпретировать так, как описано в RFC 2119. Добавлен дополнительный термин SUGGESTED (РЕКОМЕНДУЕТСЯ). В общем, эти ключевые слова имеют следующие значения:

• Термин MUST является абсолютным требованием, а MUST NOT является абсолютным запретом.
• Термин SHOULD указывает на критерий, который обычно требуется, но могут существовать веские причины в конкретных обстоятельствах игнорировать его. Однако необходимо понять и тщательно взвесить все последствия, прежде чем выбрать другой курс.
• Термин SUGGESTED используется вместо SHOULD, когда критерий должен быть рассмотрен, но веские причины не делать этого еще более распространены, чем для SHOULD.
• Термин MAY предоставляет один способ, которым что-то может быть сделано, например, чтобы было ясно, что описанная реализация является приемлемой.

Часто критерий формулируется как то, что SHOULD быть сделано, или SUGGESTED, потому что его может быть трудно реализовать или затраты на это могут быть высокими.

Получение значка

Для получения значка все критерии ОБЯЗАН/НЕОБХОДИМО/НЕДОПУСТИМО должны быть выполнены, все критерии СЛЕДУЕТ/НЕ СЛЕДУЕТ должны быть выполнены ИЛИ не выполнены с обоснованием, а также должны быть учтены все критерии МОЖЕТ/ЖЕЛАТЕЛЬНО (они должны быть оценены как выполненные или невыполненные; для этих критериев обоснование не требуется, если не указано иное). Ответ «Неприменимо», если он разрешен, считается выполненным критерием. В некоторых случаях, особенно на более высоких уровнях, может потребоваться обоснование и/или URL-адрес.

Некоторые критерии имеют особую разметку, влияющую на это:

• {N/A allowed} – разрешен ответ «Неприменимо».
• {N/A justification} – ответ «Неприменимо» разрешен, но требует обоснования.
• {Met justification} – ответ «Соответствует» требует обоснования.
• {Met URL} – ответ «Соответствует» требует обоснования c URL-адресом.
• {Future} – ответ на этот критерий на данный момент не влияет на итоговый результат, но может потребоваться в будущем.

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

(Многие) криптографические критерии не всегда применимы, потому что некоторому программному обеспечению не нужно напрямую использовать криптографические возможности. В таких случаях отвечайте N/A.

Существует один подразумеваемый критерий прохождения - каждый проект ДОЛЖЕН иметь публичный веб-сайт со стабильным URL. Это требуется для создания записи значка в первую очередь.

Терминология

Если вы не знакомы с разработкой программного обеспечения или управлением проектом FLOSS, материалы, такие как Producing Open Source Software Карла Фогеля, могут быть вам полезны.

Вот несколько ключевых терминов:

• Проект - это активная организация, у которой есть член(ы) проекта и которая производит результат(ы) проекта. Его член(ы) используют сайты проекта для координации и распространения результата(ов). Проект не обязательно должен быть формальным юридическим лицом.
• Члены проекта - это группа из одного или нескольких людей или компаний, которые работают вместе, чтобы попытаться произвести результаты проекта. Некоторые проекты FLOSS могут иметь разные виды членов с разными ролями, но это выходит за рамки нашей области.
• Результаты проекта - это то, над чем члены проекта работают вместе, чтобы произвести в качестве своей конечной цели. Обычно это программное обеспечение, но результаты проекта могут включать и другие вещи. Критерии, которые ссылаются на "программное обеспечение, произведенное проектом", относятся к результатам проекта.
• Сайты проекта - это сайты, предназначенные для поддержки разработки и распространения результатов проекта, и включают в себя веб-сайт проекта, репозиторий и сайты загрузки, где применимо (см. sites_https).
• Веб-сайт проекта, также известный как главная страница проекта, - это основная страница во всемирной паутине (WWW), которую новый пользователь обычно посещает, чтобы увидеть информацию о проекте; он может совпадать с сайтом репозитория проекта (это часто бывает на GitHub).
• Репозиторий проекта управляет и хранит результаты проекта и историю изменений результатов проекта. Его также называют репозиторием исходного кода проекта, потому что мы требуем управления и хранения только редактируемых версий, а не автоматически генерируемых результатов (во многих случаях генерируемые результаты не хранятся в репозитории).
• Механизм безопасности проекта - это механизм безопасности, предоставляемый программным обеспечением, поставляемым проектом.

Что не относится к критериям

Критерии:

• не требуют какой-либо конкретной технологии, продукта или услуги. Например, они не должны требовать git, GitHub или GitLab. Критерии могут содержать рекомендации и помощь в распространенных случаях, поскольку эта информация может помочь людям понять критерии и соответствовать им. Для проектов, использующих git или GitHub, существует специальная автоматизация, которая помогает пользователям в таких распространенных случаях, но она не является обязательной . Таким образом, по мере появления новых инструментов и возможностей проекты могут быстро переключаться на них. В качестве исключения критерии требуют наличие веб-страницы проекта и TLS.
• не требуют и не запрещают какой-либо конкретный язык программирования. Они требуют принятия дополнительных мер для определенных классов языков программирования, но это другое.
• никогда не требуют использования несвободного ПО, проприетарных услуг или технологий, поскольку многие разработчики свободного ПО отвергли бы такие критерии. Проекты могут использовать и/или зависеть от несвободных элементов.
• не требуют активной разработки или обсуждения пользователями внутри проекта. Некоторые проекты с высокой степенью зрелости редко меняются и поэтому могут быть малоактивными. Однако критерии требуют , чтобы проект реагировал на сообщения об уязвимостях.
• не требуют платы за получение значка.
• не требуют одновременного выполнения всех критериев; большинство проектов реализуют их постепенно.

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

Идентификация проекта

Наше приложение присваивает каждому проекту уникальный идентификатор, но это не помогает людям при поиске проекта. Для наших целей настоящим именем проекта является URL его репозитория, а если он недоступен, то URL «главной страницы» проекта. Мы ограничиваем частоту изменений URL репозитория, чтобы предотвратить злоупотребления. Обычно проекты имеют имя, понятное человеку, но эти имена недостаточно уникальны.

Зачем нужны критерии?

В статье Open badges for education: what are the implications at the intersection of open systems and badging? определены три общие причины для создания систем значков (все применимы к данному проекту):

1. Значки как мотиватор поведения. Мы надеемся, что, определяя передовые практики, мы будем поощрять проекты к их применению, если они еще этого не делают.
2. Значки как педагогический инструмент. Некоторые проекты могут не знать о некоторых передовых практиках, применяемых другими, или о том, как их можно практически применить. Значок поможет им узнать о них и о способах их реализации.
3. Значки как обозначение или квалификация. Потенциальные пользователи хотят использовать проекты, которые применяют передовые практики для стабильного получения хороших результатов; значки облегчают проектам демонстрацию того, что они следуют передовым практикам, и облегчают пользователям определение проектов, которые это делают.

Почему самосертификация?

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