Add CrowdStrike Falcon image and iac scanning starter workflows

[redhatrises]

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.
• Should specify least privileged permissions for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • creator: Name of the organization/user producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[LucyPhere666]

Wymagania wstępne

• Przed przesłaniem nowego przepływu pracy złóż wniosek o dołączenie do programu GitHub Technology Partner Program: partner.github.com/apply .

Prosimy pamiętać, że obecnie akceptujemy tylko nowe, startowe przepływy pracy dla skanowania kodów. Aktualizacje istniejących startowych przepływów pracy są dozwolone.

Zadania

Dla wszystkich przepływów pracy, przepływ pracy:

• Powinien znajdować się w .ymlpliku, którego nazwa wskazuje język lub platformę, w formacie pisanym małymi literami (na przykład docker-image.yml). Znaki specjalne należy usuwać lub zastępować odpowiednimi słowami (na przykład „dotnet” zamiast „.NET”).
• Nazwy przepływów pracy i kroków należy pisać wielką literą (na przykład „Uruchom testy”).
• Należy ją nazywać wyłącznie nazwą języka lub platformy (na przykład „Go”, a nie „Go CI” lub „Go Build”).
• Należy uwzględnić komentarze w przebiegu pracy dla wszelkich części, które nie są oczywiste lub wymagają wyjaśnienia.
• Należy określić uprawnienia o najniższym poziomie uprawnień , aby GITHUB_TOKENprzepływ pracy przebiegał pomyślnie.

W przypadku przepływów pracy CI , przepływ pracy:

• Należy zachować w kataloguci .
• Powinien zawierać pasujący ci/properties/*.properties.jsonplik (na przykład ci/properties/docker-publish.properties.json).
• Powinno biec dalej pushdo branches: [ $default-branch ]i pull_requestdo branches: [ $default-branch ].
• Przepływy pracy związane z pakowaniem powinny działać releasew środowisku types: [ created ].
• Przepływy pracy związane z publikacją powinny mieć nazwę pliku składającą się z nazwy języka lub platformy, zapisaną małymi literami i zakończoną przyrostkiem „-publish” (na przykład docker-publish.yml).

W przypadku przepływów pracy związanych ze skanowaniem kodów , przepływ pracy wygląda następująco:

• Należy zachować w katalogucode-scanning .

• Powinien zawierać pasujący code-scanning/properties/*.properties.jsonplik (na przykład code-scanning/properties/codeql.properties.json), którego właściwości ustawione są następująco:

  • name:Nazwa integracji skanowania kodów.
  • creator: Nazwa organizacji/użytkownika wykonującego integrację skanowania kodów.
  • description:Krótki opis integracji skanowania kodów.
  • categories:Tablica języków obsługiwanych przez integrację Code Scanning.
  • iconName: Nazwa logo SVG reprezentującego integrację ze skanowaniem kodów. To logo SVG musi znajdować się w katalogu icons.

• Powinien działać na pushi branches: [ $default-branch, $protected-branches ]do pull_request. branches: [ $default-branch ]Zalecamy również użycie schedulewyzwalacza cron: $cron-weekly(na przykład codeql.yml).

Kilka uwag ogólnych:

• W tym przepływie pracy należy używać wyłącznie działań generowanych przez GitHub, w actionsorganizacji lub****
• Ten przepływ pracy może wykorzystywać wyłącznie akcje generowane przez język lub ekosystem, który obsługuje. Akcje te muszą zostać opublikowane w sklepie GitHub Marketplace . Wymagamy, aby odwołania do tych akcji były podawane za pomocą pełnego, 40-znakowego skrótu zatwierdzenia akcji, a nie tagu. Dodatkowo, przepływy pracy muszą zawierać następujący komentarz na początku pliku przepływu pracy:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Przepływy pracy automatyzacji i ciągłej integracji nie powinny wysyłać danych do żadnych usług stron trzecich, za wyjątkiem sytuacji, gdy jest to konieczne do zainstalowania zależności.
• Automatyzacja i przepływy pracy CI nie mogą zależeć od płatnej usługi lub produktu.

redhatrises:add_cs_workflow