CPS получил OpenSSF Gold: как на практике выглядит «secure OSS»

Open Source Security Foundation (OpenSSF) сообщает, что проект Configuration Persistence Service (CPS) достиг уровня OpenSSF Best Practices “Gold”. CPS описывается как компонент-репозиторий данных с фокусом на persistence внутри ONAP (Open Network Automation Platform), который используется в телеком- и network automation-сценариях, где сбои надежности и нарушения целостности могут иметь высокий ущерб.

Это не disclosure уязвимости и не разбор exploit. Это история про процессы: как один open source-проект заявляет, что выполнил требования высшего уровня в широко используемом checklist по security и development practices, и что другие команды могут из этого вынести без излишней романтизации badge.

Что произошло и что на самом деле означает этот badge#

Badge OpenSSF Best Practices предназначены для того, чтобы показать: проект Free/Libre and Open Source Software (FLOSS) следует набору документированных практик в таких областях, как governance проекта, качество кода, тестирование и security controls. В публикации OpenSSF уровень Gold подается как самый строгий во всех категориях — выше, чем “Passing” и “Silver”.

В посте CPS представлен как первый проект в более широком сообществе Linux Foundation Networking (LFN), достигший Gold. Это заявление о «первенстве» важно прежде всего как сигнал organizational maturity: оно подразумевает, что проект не только улучшил собственный repo, но и подтолкнул развитие общей infrastructure и требований на уровне всего сообщества.

Чего этот badge сам по себе не доказывает:

• что CPS «secure» в абсолютном смысле;
• что в CPS нет уязвимостей;
• что у CPS идеальная runtime-защита от misconfiguration, ошибок операторов или compromise в supply chain.

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

Что, по словам CPS, было изменено: quality gates, глубина тестирования и security в CI#

В посте OpenSSF описывается трехлетняя работа, построенная на трех pillars: качество кода, строгость тестирования и security-first mindset.

Качество кода: обязательные стандарты и осознанное усложнение review#

CPS сообщает, что проект:

• следует Google Java style и ONAP checkstyle, чтобы код оставался единообразным и поддерживаемым;
• в качестве политики ставит исправление bug выше новых features;
• требует merge checklist с минимум тремя reviewers, включая владельца work item и senior developer.

Ничего революционно нового здесь нет, но ключевая деталь — именно enforcement. Фраза «у нас есть style guide» почти ничего не стоит; фраза «изменение не будет влито, если оно не соответствует style и не прошло минимальные требования review» — это уже реальный контроль.

Тестирование: shift-left для integration и ранние проверки performance#

CPS описывает многоуровневую стратегию тестирования:

• Unit tests для изменений в коде с использованием Groovy и Spock;
• слой «semi-integration» с использованием Testcontainers (для database и Kafka) и stubs для внешних зависимостей;
• отдельное полноценное end-to-end testing команда по-прежнему проводит отдельно, но в посте утверждается, что внутренних integration-проблем, которые не были бы пойманы раньше, они уже не видят — если только причина не во внешней configuration.

Отдельно отмечена практика performance testing, встроенного в unit tests. В качестве примера в посте приводится использование PostgreSQL containers для тестирования алгоритмов и раннего обнаружения regressions.

Этот момент легко пропустить, но он очень практичен: многие проекты замечают провал performance только после релиза, потому что performance tests живут «где-то отдельно» — или не существуют вовсе. Когда performance checks встроены в обычный CI, игнорировать их становится гораздо сложнее.

Coverage gates: что заявлено и что не уточняется#

В посте упоминаются SonarQube/SonarCloud и говорится, что coverage сейчас составляет 100% во всех модулях, кроме одного, а также что проект требует 100% coverage и отдельно — “on all new and modified code” before merge.

Похоже, что исходный текст местами обрезан, поэтому только по этому фрагменту невозможно точно пересказать каждую метрику (например, точный исторический уровень coverage в нем отсутствует). Но практический вывод все равно очевиден: CPS рассматривает пороги coverage как merge gate для измененного кода, а не как vanity-метрику для dashboard.

Security-first в CI/CD: scanning, hygiene релизов и защита трафика#

CPS описывает security-контроли как часть pipeline-процессов:

• поддержание актуальности best practices силами project technical leader (PTL) и команды;
• использование SonarCloud для обнаружения уязвимостей и устранение findings как в текущих, так и в предыдущих релизах;
• совместимость с реализацией service mesh в ONAP, при этом в посте делается акцент на encryption in transit для снижения риска несанкционированного доступа к данным.

Для инфраструктурных компонентов с большим количеством зависимостей это в основном practices уровня “table stakes”. Они не гарантируют отсутствие инцидентов, но заметно повышают базовую дисциплину разработки и эксплуатации.