Automation-repetitive-task-software

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

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 8239 - gold Вот как вставить его:
Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/8239/badge)](https://www.bestpractices.dev/projects/8239)
- или HTML:
<a href="https://www.bestpractices.dev/projects/8239"><img src="https://www.bestpractices.dev/projects/8239/badge"></a>


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

        

 Основы 5/5 ●

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

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

    Tremendous automation repetitive task Sofware with the motive of contributing to what makes your day to day activities much easier and accessible for you at your work place.

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


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

    Проект ОБЯЗАН получить серебряный значок. [achieve_silver]

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


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

    Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    Thank you for the opportunity to share the details about my work. However, I was able to acquire the Digital object identification badge through zenodo which makes all my research contributions and recognition attributed to me. The DOI provides a comprehensive bus factor where Bus factor was linked to my GitHub account through the zenodo website. URL: https://zenodo.org/records/10829824


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

    Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) [contributors_unassociated]
    Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.

    https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/releases https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/pull/72


  • Другое


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

    Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. [license_per_file]
    Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

    I added Apache License file for my project and it can be downloaded from my GitHub repository. https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/blob/main/Apache%20license


 Управление изменениями 4/4 ●

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


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

    Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

    Repository on GitHub, which uses git. git is distributed.


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

    Проект ОБЯЗАН четко обозначать небольшие задачи, которые могут быть выполнены новыми или случайными участниками. (Требуется URL) [small_tasks]
    Это обозначение обычно делается путем маркировки выбранных проблем в трекере одним или несколькими тегами, которые использует проект для этой цели, например up-for-grabs, «только для новичков», «Небольшое исправление», «микрозадача» или IdealFirstBug. Эти новые задачи не обязательно требуют добавления функциональности; это может быть улучшение документации, добавление тестовых кейсов или что-то еще, что помогает проекту и помогает участнику лучше понять проект.

    Yes a demo repository has been automated to ensure that any contributions or new user pass the test before proceeding to the next task on the project. URL: https://github.com/KIDI-S-TECH/demo-repository


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

    Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. [require_2FA]

    The two-factor authentication (2fA) for developers for changing a central repository or accessing sensitive data. This was set up on the production stage of my project.


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

    При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. [secure_2FA]
    Механизм ДФА, который соответствует этому критерию, может быть приложением для генерации временных одноразовых паролей (Time-based One-Time Password, TOTP), которое автоматически генерирует код аутентификации, меняющийся через определенный промежуток времени. Обратите внимание, что GitHub поддерживает TOTP.

    I understand the security protocols of 2FA and i used it on my project because my account on GitHub has a security layer that allows my account access to all my projects to pass through TOTP.


 Качество 7/7 ●

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


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

    Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. (Требуется URL) [code_review_standards]
    См. также критерии two_person_review и contrib_requirements.

    This was met on my repository and can be seen on my project url. All code standard were created and implemented in a very simple way with the help of my own project and it’ll be more easier for users or first time users to understand what the project was built for. URL: https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/blob/main/README.md


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

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

    This was kinda met because it was hard finding someone who would audit my progress on my project. But it got over 950 clones with over 2k views on GitHub. With no issues or complaints from users However it was tested and modified for months before it was even released. So all production code and all the work was completed in a timely manner to ensure that the project will continue to grow and be successful.


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


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

    Проект ОБЯЗАН обеспечивать воспроизводимую сборку. Если сборка не требуется (например, в случае языков сценариев, где исходный код используется непосредственно вместо компиляции), выберите «N/A». (Требуется URL) [build_reproducible]
    Воспроизводимая сборка означает, что несколько сторон могут независимо повторить процесс генерации информации из исходных файлов и получить аналогичный результат с точностью до бита. В некоторых случаях воспроизводимости можно достичь путем принудительного выставления окружения. Разработчики JavaScript могут рассмотреть возможность использования npm shrinkwrap и webpack OccurenceOrderPlugin. Пользователи GCC и clang могут найти полезной опцию -frandom-seed. Среда сборки (включая набор инструментов) часто может быть определена для внешних сторон путём указания криптографической суммы (hash) для конкретного контейнера или виртуальной машины, которые они могут использовать для пересборки. В проекте Reproducible Builds есть документация о том, как это сделать.

    Yes this project is reproducible build. Because it can also be accessed or produced new features directly from the source code from the release note. URL: https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/archive/refs/tags/v3.zip


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


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

    Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. (Требуется URL) [test_invocation]
    Например, «make check», «mvn test» или «rake test» (Ruby).

    An html file was used to test the code in a way it pass the automation test and then run the code to test or confirmation. It passed the test and was awarded an html passing badge URL: https://github.com/KIDI-STECH/demo-repository


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

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

    yes, it does. the link below is a great one to jump on in reference to how continuous integration the software can run when codes are changed frequently. though it depends on what was removed and replaced on my software. for more details on how to use, the link below will redirect to my README.md for proper review. https://github.com/KIDI-S-TECH/demo-repository


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

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

    CodeQL was used as. FlOSS automated test which validates all the tests or pull requests on the project and analyze all the data to determine how much data was collected from the project. And this measures its criterion in the selected language JavaScript


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

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

    The Floss automated test suite was done on the master branch on GitHub before pushing to the main branch. I used Git bash for my CI for continuous integration and Automation.


 Безопасность 5/5 ●

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

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

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

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

    My project supports the secure protocol for all of its network communication. The URL: https://github.com/KIDI-S-TECH/Automation-repetitive-task-software.git


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

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

    The project is been built under a secured domain name protocol HTTPS which allows users to access the network without having to worry about security. Also it supports all protocols for network communication. URL: https://github.com/KIDI-S-TECH/Automation-repetitive-task-software.git


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


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

    Веб-сайт проекта, репозиторий (если он доступен через Интернет) и сайт загрузки (если он существует отдельно) ОБЯЗАНЫ использовать упрочняющие безопасность (hardening) заголовки с неразрешающими значениями. (Требуется URL) [hardened_site]
    Обратите внимание, что GitHub отвечает этому критерию. Такие сайты как https://securityheaders.io/ могут быстро проверить использование. Ключевыми заголовками для упрочнения являются: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (выставленный в «nosniff»), X-Frame-Options и X-XSS-Protection. Статические веб-сайты без возможности входа в систему через веб-страницы могут опускать упрочняющие HTTP-заголовки CSP и X-XSS-Protection, поскольку в этом случае эти заголовки менее эффективны.

    Found all required security hardening headers. Repository git website: https://github.com/KIDI-S-TECH/Automation-repetitive-task-software.git Normal website: https://github.com/KidiIT/Automation-repetitive-task-software My project follows the best practices of using a secure network protocol on the header packet. (HTTPS) the best part is that Man in the Middle attacks will find it hard to get any useful information when any secure connection or transaction is made in the server.


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


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

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

    This project was developed and launched last 6 months. So in this case all the security requirements was met and no issues were found or reported on the roadmap of the project.


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

    В ПО, создаваемом проектом, НЕОБХОДИМО использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. (Требуется URL) [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    MFA has been implemented on the project. Which allows me the owner to verify my identity in two or three ways before I could access some certain information on my project. This reduces security vulnerabilities and software defects https://github.com/KIDI-S-TECH/Automation-repetitive-task-software/blob/main/SECURITY.md


 Анализ 2/2 ●

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


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

    Проект ОБЯЗАН применять хотя бы один инструмент динамического анализа к любой предлагаемой основной версии ПО, создаваемого проектом до её выпуска. [dynamic_analysis]
    Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

    The software uses codeQL analysis tool which helps to keep the software updated to its latest version. Also with the help of the dependabot.yml plugin that was configured on the project also helps to keep the project updated to its latest version and release. URL: https://github.com/KidiIT/Automation-repetitive-task-software/releases


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

    Проекту СЛЕДУЕТ включать достаточно много утверждений (assertions) времени выполнения в создаваемом им ПО и проверять эти утверждения во время динамического анализа. [dynamic_analysis_enable_assertions]
    Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

    I configured a codeQL code analysis file and dependencies run that focus on every single Check run test on the project. After which it output the report with a debug terminal to debug the issue directly on the repository if the check failed.



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

Владелец анкеты на значок проекта: KIDI'S-TECH.
2023-12-25 23:03:33 UTC, последнее изменение сделано 2024-05-31 18:18:13 UTC. Последний раз условия для получения значка были выполнены 2024-05-02 15:25:30 UTC.

Назад