ONAP ESR (External System Register)

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

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

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

        

 Основы 13/13

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

    ONAP components need to talk with external systems such as VIM/VNFM/vendor SDNC/EMS to orchestrate a network service, for example, VF-C need to talk with VNFM to deploy a VNF. So they should get the information of available external systems from a registry before call the Interfaces of these external systems. ESR provides a service to centralized management of the information (name, vendor, version, acess end point, etc.) of external systems. So the ONAP components can get the system information with unified API from a logical single point.

    Какие языки программирования используются для реализации проекта?
  • Основная информация на веб-сайте проекта


    Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). [description_good]

    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    The following URLs describe the process to join the community, developing the software and provide feekback: https://wiki.onap.org/display/DW/Joining+the+Community https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA https://wiki.onap.org/display/DW/Developing+ONAP



    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]

    The process could be found in the following URL: https://wiki.onap.org/display/DW/Development+Procedures+and+Policies



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

    https://wiki.onap.org/display/DW/Development+Procedures+and+Policies describes requirements for acceptable contributions and is linked from the AAI project page. https://wiki.onap.org/display/DW/Java+code+style shows java code style. https://wiki.onap.org/display/DW/Developer+Best+Practices Here is the google java code style: https://google.github.io/styleguide/javaguide.html


  • Свободная лицензия

    Под какой/какими лицензией/ями выпускается проект?



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

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



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


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

    The documentation describing the project can be found in http://onap.readthedocs.io/en/latest/submodules/aai/esr-server.git/docs/index.html



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

    ESR server end need to expose API for ESR gui. These API descriped in http://onap.readthedocs.io/en/latest/submodules/aai/esr-server.git/docs/platform/offeredapis.html ESR server will consume the API from AAI to store external system data, and API from multi-cloud to inform Multi-cloud update the VIM data. The API ESR server consumed see http://onap.readthedocs.io/en/latest/submodules/aai/esr-server.git/docs/platform/consumedapis.html


  • Другое


    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]

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

    A mailing list is used for project related discussion. New users could also check, search the old discussion online at onap-discuss website. Joining the Community: https://wiki.onap.org/display/DW/Joining+the+Community



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

    JIRA is used to track bugs. The whole website is in English. Tracking Issues with JIRA. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA



    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]


(Дополнительно) Какие другие пользователи имеют дополнительные права на редактирование этой записи значка? В настоящее время: [2058, 6064]



  • Публичное хранилище исходного кода с поддержкой версий


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

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

    Tracking is provided by using a combination of JIRA and git history. Every commit has an user and a Jira number attached to it. Git history for esr-server's master branch: https://gerrit.onap.org/r/gitweb?p=aai/esr-server.git;a=shortlog;h=refs/heads/master Jira for ONAP: https://jira.onap.org/secure/Dashboard.jspa



    Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. [repo_interim]

    Gerrit provides an temperate branch for reviewing and providing comments. Once approved, the code will be merged and the temperate branch will be removed.



    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]

    Git and Gerrit are used. For detail see https://gerrit.onap.org/r/gitweb?p=aai/esr-server.git;a=summary


  • Уникальная нумерация версий


    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]

    Release version is with format ${major}.${minor}.${patch} and will be updated accordingly for each release. See https://gerrit.onap.org/r/gitweb?p=aai/esr-server.git;a=blob;f=version.properties;h=e2595ba14c932d19f02efe8ecb4e04901e1ea36f;hb=HEAD



    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]


    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]
  • Примечания к выпуску


    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]

    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]

    Release notes with identified vulnerabilities can be found in http://onap.readthedocs.io/en/latest/submodules/aai/esr-server.git/docs/release-notes/index.html

    No vulnerabilities have yet been identified.


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


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

    The description of the process can be found in the following URL: https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA



    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    The reported issues are being handled as soon as possible.



    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]

    The reported issues are being handled as soon as possible.



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


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

    The process on how to report a vulnerability can be found in https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management



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

    Private vulnerability reports are not supported.



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

    There's no vulnerabilities reported so far.


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


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

    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]

    Maven is used to build the project.



    Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. [build_floss_tools]

    Maven is under Apache 2.0 liscense.


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


    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]

    This project uses Log4j for unit test and robot framework for functional test. Tests are automatically running at Jenkins: https://jenkins.onap.org/view/aai/



    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]

    The combination Junit and robot test suite has the ability to cover most of the branches, input fields and functionality.



    ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. [test_most]

    The combination Junit and robot test suite has the ability to cover most of the branches, input fields and functionality.



    ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). [test_continuous_integration]

    For each pull request, the project needs to be built successfully before the Merge option becomes activated. The test will be run automatically during the building process as well. Once build successfully and all tests have passed, the Merge option will be activated.


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


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

    The code coverage requirement is listed as a developer best practice here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis So when new functionality is added, tests of that functionality should be added as well to meet the code coverage requirement.



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

    Sonar is used to monitor the code coverage and make sure that the test_policy for adding tests has been adhered to.



    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]

    The code coverage requirement is listed as a developer best practice here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis


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


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

    This project is using sonar(https://sonar.onap.org) to look for code quality errors or common simple mistakes.



    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]

    The warnings are being handled as soon as possible.



    ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. [warnings_strict]

    This project is using sonar(https://sonar.onap.org) to look for code quality errors or common simple mistakes, which has comprehensive rules(more than 200) to check the codes, all the findings are listed in the quality report.


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


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


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

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

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

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


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


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


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


    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]


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

    We disallow SHA-1 or other insecure cryptographic algorithms.



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


    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]


    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]

  • Доставка, защищенная от атак посредника (MITM)


    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]


    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]

  • Исправление обнародованных уязвимостей


    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]

    ONAP has a sub-committee and an expert team to manage the vulnerability and coordinate projects to handle them when reported: https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management



    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

    ONAP has a sub-committee and an expert team to manage the vulnerability and coordinate projects to handle them when reported: https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management


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


    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]

    No private credential in the public repositories.


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


    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]

    This project is using sonar(https://sonar.onap.org) to look for static code analysis



    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]

    This project is using nexus iq(https://nexus-iq.wl.linuxfoundation.org) to look for common vulnerabilities



    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]


    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

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


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


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


    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]


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


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

Владелец анкеты на значок проекта: mrsjackson76.
2018-01-30 03:06:27 UTC, последнее изменение сделано 2019-08-05 14:07:43 UTC. Последний раз условия для получения значка были выполнены 2019-04-26 15:10:34 UTC.

Назад