ONAP AAF (Application Authorization Framework)

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 2303 - in_progress Вот как вставить его:

Это критерии уровня Silver. Вы также можете просмотреть критерии уровня Passing или Gold.

        

 Основы 16/17 ●

  • Идентификация

    AAF is designed to cover Fine-Grained Authorization, meaning that the Authorizations provided are able to used an Application’s detailed authorizations, such as whether a user may be on a particular page or has access to a particular Pub-SUB topic controlled within the App.

    AAF's Client Framework, "CADI" provide multi-Authentication to a normalized identity, which is paired with Authorization to provide full validation of incoming transaction before processing.

    These are critical functions for Cloud environments, as Services need to be able to be installed and running in a very short time, and should not be encumbered with local stores of User Password and/or Permissions.

  • Предварительные требования


    Недостаточно для значка.

    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

  • Основная информация на веб-сайте проекта


    Достаточно для значка!

    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

    https://wiki.onap.org/display/DW/Developing+ONAP


  • Надзор за проектом


    Достаточно для значка!

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]

    ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA). https://wiki.onap.org/display/DW/Contribution+Agreements


    Достаточно для значка!

    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]

    The project governance is described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Further information can be found at https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document


    Достаточно для значка!

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]

    ONAP adheres to the Linux Foundation Code of Conduct, found at https://lfprojects.org/policies/code-of-conduct


    Достаточно для значка!

    Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. (Требуется URL) [roles_responsibilities]

    The key roles in the project and their responsibilities are described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Current members are listed at https://wiki.onap.org/pages/viewpage.action?pageId=8226539


    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    We have 4 committers and multiple contributes who are listed in https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-ActiveandAvailableInventory All 4 committers have access and rights to maintain the code base, approve and review incoming changes and release a new version of the artifact. This will let the project continue with minimal to no interruption if one person is incapacitated. Also this project is controlled by the linux foundation so we can add more committers if needed


    Достаточно для значка!

    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]

    All the projects covered in this report have more than 2 persons who actively contribute and maintain code. https://gerrit.onap.org/r/#/q/project:aaf/authz https://gerrit.onap.org/r/#/q/project:aaf/cadi


  • Документация


    Достаточно для значка!

    Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. (Требуется URL) [documentation_roadmap]

    https://wiki.onap.org/display/DW/Pre-Release+Planning+and+Notes


    Достаточно для значка!

    Проект ОБЯЗАН включать документацию по архитектуре (также называемой высокоуровневым дизайном) ПО, создаваемого проектом. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. (Требуется URL) [documentation_architecture]

    https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/architecture/index.html


    Достаточно для значка!

    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [documentation_security]

    https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/architecture/security.html


    Достаточно для значка!

    Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. (Требуется URL) [documentation_quick_start]

    Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-develo:per/settingup/index.html AAF Specific info https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/installation/index.html https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/sections/configuration/index.html


    Достаточно для значка!

    Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. [documentation_current]

    Documentation is updated with each release (using readthedocs.io strategy)


    Достаточно для значка!

    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]

    The badge is visible on the project's readme.io page found at https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/index.html


  • Общедоступность и интернационализация


    Достаточно для значка!

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]

    Most of AAF is Service Based. Colors for Management GUI were chosen by ONAP Standards for readability. Standards for Field identification are followed, for instance, "Required" are not just red, but have Asterix'


    Достаточно для значка!

    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]

    Most of AAF is Service Based, and text entered is user defined. It is, however, designed primarily for Developers/IT Professionals, so English (as instructed) is first language of logging, etc.


  • Другое


    Достаточно для значка!

    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]

    AAF Tool is intended to delegate User/Password to the Organization. When this is not available, however, AAF stores as salted-SHA256 Hashes. Certificate Authentication (Provided) is promoted above any use of User/Password.


  • Предыдущие версии


    Достаточно для значка!

    Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (upgrade path). Если переход затруднен, проект ОБЯЗАН задокументировать порядок обновления (например, изменившиеся интерфейсы и подробные предлагаемые шаги для обновления). [maintenance_or_update]

    All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed


  • Процесс сообщения об ошибках


    Достаточно для значка!

    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA


  • Процесс отчета об уязвимостях


    Достаточно для значка!

    Проект ОБЯЗАН отмечать автора(-ов) всех отчетов об уязвимостях, разрешенных за последние 12 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [vulnerability_report_credit]

    Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we dont have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.


    Достаточно для значка!

    Проект ОБЯЗАН иметь документированный процесс реагирования на отчеты об уязвимостях. (Требуется URL) [vulnerability_response_process]

    Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711


  • Стандарты кодирования


    Достаточно для значка!

    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [coding_standards]

    Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style


    Достаточно для значка!

    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]

    SONAR compile time and Static Reporting tools enforce coding styles.


  • Рабочая система сборки


    Достаточно для значка!

    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]

    AAF is written in Java, "run everywhere" on JVM.


    Достаточно для значка!

    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]

    The application does not create native binaries. All build info generated by Maven are stored as Jenkins Outputs for Job.


    Достаточно для значка!

    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]

    AAF deliberately and specifically has no cross dependencies for artifacts.


    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии повторить процесс генерации информации из исходных файлов и получить такой же результат с точностью до бита. Выберите «неприменимо» (N/A), если в проекте не используется сборка (например, языки сценариев, в которых исходный код используется непосредственно вместо компиляции), . [build_repeatable]

    The application does not create native binaries. AAF jars are always generated exactly the same way, with the same results, per source code set.


  • Система установки


    Достаточно для значка!

    Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. [installation_common]

    Source is delivered as Java Jars. Docker Containers are also generated, for use in either Docker Directly, or within Kubernetes.


    Достаточно для значка!

    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    The compiled docker images and jar files can be installed/used as the user sees fit. Both run on JVM or docker. So there is no reason to selecting locations etc.


    Достаточно для значка!

    Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. [installation_development_quick]

    All the components require only java and maven to begin with for a developer to quickly install and test it.

    Even for deployment using OOM and the right amount of resources, we can deploy the full AAI/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html


  • Компоненты, поддерживаемые извне


    Достаточно для значка!

    Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. (Требуется URL) [external_dependencies]

    External dependencies are controlled using the pom file, which can be found in the root folder for the project, https://gerrit.onap.org/r/gitweb?p=aaf/authz.git;a=tree


    Достаточно для значка!

    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]

    NexusIQ sonar scan is run on all the projects on a weekly basis


    Достаточно для значка!

    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]

    External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit


    Достаточно для значка!

    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    We avoid depending on deprecated/obsolete functions.


  • Набор автотестов


    Достаточно для значка!

    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]

    Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.


    Достаточно для значка!

    Проект ОБЯЗАН добавить регрессионные тесты к автоматизированному набору тестов по крайней мере на 50% ошибок, исправленных в течение последних шести месяцев. [regression_tests_added50]

    When regressions occur, we add tests for them.


    Достаточно для значка!

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]

    We use sonar to measure the code coverage. https://sonar.onap.org/about


  • Тестирование новых функций


    Достаточно для значка!

    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies


    Достаточно для значка!

    Проект ОБЯЗАН включать в свои документированные инструкции для предложений об изменениях политику, по которой для существенной новой функциональности должны добавляться тесты. [tests_documented_added]

    This is documented on our wiki: Code Coverage and Static Code Analysis


  • Флаги предупреждений


    Достаточно для значка!

    Проекты ОБЯЗАНЫ быть максимально строгими с предупреждениями в ПО, создаваемом проектом, где это целесообразно. [warnings_strict]

    Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.


  • Знание безопасной разработки


    Достаточно для значка!

    Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. [implement_secure_design]

    AAF and CADI are designed to help applications meet Secure Principles, using best available Cryptography and practices (i.e. HTTP/S, TLS 1.1+, Certificates, etc)


  • Основы правильного использования криптографии

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

    Достаточно для значка!

    В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]

    AAF's CADI Framework defaults usage of TLS 1.1+


    Достаточно для значка!

    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    Algorithms are provided by Java, which are constantly being updated. Often, a simple upgrade to a later JDK is all that is required.


    Достаточно для значка!

    Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. [crypto_credential_agility]

    AAF's CADI framework provides the ability to encrypt all passwords from Config Files, access to JKS/P12 files, etc. No clear text passwords are allowed within the configuration.


    Достаточно для значка!

    В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    AAF/CADI defaults all clients to HTTP/S TLS1.1 & TLS1.2 from the outset.


    Достаточно для значка!

    Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    AAF/CADI defaults all clients to HTTP/S TLS1.1 & TLS1.2 from the outset.


    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]

    TLS processing is handled by Java


    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_verification_private]

    CADI Clients do not allow HTTP... only HTTP/S, and these are defaulted to TLS 1.1+


  • Безопасный выпуск


    Достаточно для значка!

    Проект ОБЯЗАН криптографически подписывать выпуски результатов проекта, предназначенные для широкого использования, и ОБЯЗАН иметь задокументированный процесс, объясняющий пользователям, как они могут получить общедоступные ключи подписи и проверить подпись(и) выпусков. НЕДОПУСТИМО размещать закрытый ключ для этих подписей на сайте(сайтах), используемом для прямого распространения ПО для общественности. Выберите «неприменимо» (N/A), если выпуски не предназначены для широкого использования. [signed_releases]

    All release artifacts are signed by the Linux Foundation prior to release.


    Достаточно для значка!

    ЖЕЛАТЕЛЬНО, чтобы в системе контроля версий каждый важный тег версии (тег, который является частью основного выпуска, минорной версии или исправляет общедоступные уязвимости) подписывался криптографической подписью и поддавался проверке, как описано в критерииsigned_releases. [version_tags_signed]

    All releases (which are tagged major/minor/patch) are signed by Linux Foundation.


  • Другие вопросы безопасности


    Достаточно для значка!

    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]

    AAF/CADI always requires both Authentication, and Authorization. That is actually the purpose of this software to enable Apps to also always require Authentication and Authorization in a Fine-grained manner.


    Достаточно для значка!

    В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]

    The project tries to use hardening mechanism whenever possible. AAF (and CADI) log all secure transactions, with critical info, such as kind of Authentication, the ID, the IP , etc.


    Достаточно для значка!

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]

    AAF/CADI is itself a security framework for Authentication and Authorization . What it does is all documented in the initial docs.

    https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/index.html


  • Статический анализ кода


    Достаточно для значка!

    Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. [static_analysis_common_vulnerabilities]

    https://sonar.onap.org


  • Динамический анализ кода


    Достаточно для значка!

    Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]

    All the projects use Java which are memory safe that run on JVM. Also the end product runs on a docker container which is run on docker.



Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 или более поздней (CC-BY-3.0+). Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "mrsjackson76 and the OpenSSF Best Practices badge contributors".

Владелец анкеты на значок проекта: mrsjackson76.
2018-10-24 14:42:40 UTC, последнее изменение сделано 2021-04-14 13:39:48 UTC. Значок последний раз потерян 2021-04-14 13:39:48 UTC. Последний раз условия для получения значка были выполнены 2018-10-24 15:33:51 UTC.

Назад