Github Security

왜 사용하나

오픈소스와 같은 많은 사용자들이 이용하는 소스코드에 취약점이 발견 될 경우, Security 탭에서 취약점을 보고 할 수 있다.

취약점을 보고 할 경우 가시성은 해당 레포지토리의 관리자 및 협력자에게만 표시되며, 이를 통해 해당 취약점을 내부 관계자들이 파악하고 조치할 수 있다.

Github Security Policy

저장소에 보안 정책을 추가하여 프로젝트의 보안 취약점을 보고하는 방법에 대한 지침을 제공 할 수 있다.

Github 에서는 각 레포지토리마다 각자의 다양한 정책을 가지고 있다. 예를 들면 Pull Request Template, Issue Template 또는 Contributor가 되기 위해 미리 숙지 해야할 것들과 같이, 보안 이슈를 보고하기 위해서도 사용자들이 보안 취약점을 보고하기 위한 가이드를 제공할 수 있다.

어떻게?

저장소의 루트, docs, .github 폴더에 SECURITY.md 파일을 추가할 수 있다. 이 파일을 앞에 언급한 저장소의 폴더에 생성 할 경우 사람들이 검토할 수 있는 설명이 있는 행이 자동으로 생성된다.

이를 통해 다른 사용자가 취약점 보고를 위한 가이드라인과 정보를 얻을 수 있다.

Github Report Vulnerabilities

만약 레포지토리의 소스코드에서 보안 취약점을 발견 한 경우 Private vulnerability reporting 을 활성화 하여 사용자들로부터 보안 취약점 보고를 받을 수 있다.

이를 활성화 한 경우 보안 취약점을 보고 할 수 있는데, 아래와 같은 폼으로 해당 보안 취약점에 대해 자세히 설명할 수 있다.

아무래도 보안 취약점이므로, 어떤 문제가 발생하는지, 이슈 재연 시나리오 및 해당 취약점을 검증하는 프로세스가 기본 폼으로 작성되어 있다.

마무리

짧지만, 최근들어 Github Foundations를 공부하면서 Github에서 제공하는 다양한 기능들을 간단히 소개해보고자 한다. Github Foundations는 국내에서 검색했을 때 자료가 없었고, 여기서 배운 내용들이 한국 개발자들이 Github를 더 효율적으로 사용하고, 필요했었지만 기능의 존재 유무조차 알지 못해 넘어갔던 부분들을 어느정도 해소시킬 수 있지 않을까 생각한다.

Github Issue Form

Github를 사용하면서 주로 이슈 템플릿을 활용하여 이슈를 관리 했었는데, Github Foundations를 공부하면서 다른 형식으로 이슈 관리를 제공하는 Issue Form에 대해 알게되어 소개하고자 글을 포스팅 합니다.

이미 Github Issue Template를 사용해 본 경험이 있고, Github에 친숙한 분들을 대상으로 빠르게 글을 작성해봅니다.

Issue Form 생성하기

Issue Form은 기존 이슈 템플릿과 동일하게 레포지토리 내의 .github/ISSUE_TEMPLATE/ 경로에서 이슈 폼 파일을 정의할 수 있습니다.

사용하고자 하는 폼의 유형에 따라 .yml 파일을 정의하면 되는데, Github 문서 에서 제공하는 기본 이슈 폼을 그대로 작성해보겠습니다.

아래의 내용으로 .github/ISSUE_TEMPLATE/bug.yml 파일을 생성 합니다.

자세한 yml 파일 구성 양식은 Github Issue Form 공식 문서에서 확인할 수 있습니다.

https://docs.github.com/ko/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

name: Bug Report
description: File a bug report.
title: "[Bug]: "
labels: ["bug", "triage"]
projects: ["octo-org/1", "octo-org/44"]
assignees:
  - octocat
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: input
    id: contact
    attributes:
      label: Contact Details
      description: How can we get in touch with you if we need more info?
      placeholder: ex. email@example.com
    validations:
      required: false
  - type: textarea
    id: what-happened
    attributes:
      label: What happened?
      description: Also tell us, what did you expect to happen?
      placeholder: Tell us what you see!
      value: "A bug happened!"
    validations:
      required: true
  - type: dropdown
    id: version
    attributes:
      label: Version
      description: What version of our software are you running?
      options:
        - 1.0.2 (Default)
        - 1.0.3 (Edge)
      default: 0
    validations:
      required: true
  - type: dropdown
    id: browsers
    attributes:
      label: What browsers are you seeing the problem on?
      multiple: true
      options:
        - Firefox
        - Chrome
        - Safari
        - Microsoft Edge
  - type: textarea
    id: logs
    attributes:
      label: Relevant log output
      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
      render: shell
  - type: checkboxes
    id: terms
    attributes:
      label: Code of Conduct
      description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com). 
      options:
        - label: I agree to follow this project's Code of Conduct
          required: true

성공적으로 레포지토리 내에 파일을 생성 한 경우, Github에서 새로운 이슈를 생성하면 다음과 같이 이슈 폼을 선택할 수 있습니다.

이슈 생성 화면을 보면 기존 이슈 템플릿보다 편리하고 구조화된 이슈를 생성하는 폼을 제공합니다. 

생성된 이슈는 이슈 템플릿으로 생성한 형식과 동일하게 표시됩니다.

이슈폼을 직접 생성해보면서 느낀점은 이슈의 형식에 좀더 제한을 두어, 더욱더 강력하고 편리하게 이슈를 관리할 수 있겠다고 느꼈습니다. 다음에 Github 에서 프로젝트를 관리할 일이 생긴다면, 이슈 폼을 적극 도입하지 않을까 합니다.

또한, 현재 이슈 폼은 베타 버전으로 언제든지 변경될 가능성이 있다고 합니다.

첫 오픈소스 기여 후기

2024년 취업과 동시에 여러가지 목표가 있었는데, 그 중 하나인 오픈소스 기여를 매우 간단하게 성공했던 후기를 공유해보고자 한다. 많은 개발자들이 어렵게 생각하는 만큼, 나 역시 “나 같은 하찮은 개발자가 오픈소스에 기여할 수 있을까?” 고민 했었지만, 역시 일단 하고 두들겨 맞는게 가장 빠르게 목표를 달성할 수 있다고 생각하여 오픈소스에 기여할 방법을 찾아봤다.

오픈소스 기여 대상 탐색

처음에는 Github에서 Major한? 프레임워크(Vue.js, Spring Framework)를 대상으로 기여를 하려고 했으나, 이미 많은 사람들이 참여하고 있는 프로젝트들인 만큼 내가 기여할 수 있는 부분을 빠르게 찾기는 어려웠다. 그래서, SSAFY 자율 프로젝트 진행 중 피쳐플래깅 서비스로 레퍼런스에 이용했었던 Unleash라는 서비스를 보던 중, 충분히 납득할만한 기여사항을 발견하여 이 프로젝트의 문서화에 기여하기로 했다.

문서화 기여

해당 서비스는 피쳐 플래깅 서비스의 Java측 SDK로, ReadMe에 해당 서비스를 사용하기 위한 설정들이 적혀 있었는데, Maven 프로젝트 기준으로 세팅하는 방법이 적혀 있었다. 나는 평소 Gradle로만 프로젝트를 진행했었고, 많은 주니어 개발자들이 비슷한 경험을 했을것이라고 생각했다. 따라서, Gradle로 SDK 의존성을 추가하는 간단한 ReadMe를 작성했다.

아주 하찮은 수정사항이지만 해당 수정사항을 반영해야 하는 이유에 대해서 정성스레 PR을 올렸고, PR을 올린지 두시간만에 리뷰어님이 Approve와 함께 Merge를 진행해주셨다.

오픈소스 기여 후기

오픈소스에 기여하는것이 3년 이내에 해야할 버킷리스트에 포함되어 있을만큼 도전해보고 싶었던 일인데 정말 쉽고 빠르게 목표를 달성하여 기분이 좋기도 하고, 왜 진작 시도해보지 않았을까? 라는 생각도 든다. 비록 지금은 문서 수정이지만 앞으로 여러 오픈소스 프로젝트에 참여하고 국내 및 해외 개발자들과 소통하며 다양한 경험을 하고싶다.

1. Github 사이트에서 새로운 레포지토리 생성하기 github.com/new 

2. 생성한 레포지토리 주소 복사하기 

3. 연동할 로컬 저장소 위치로 이동하기. ( ex) C:\Users\HyeonWoo\repository)

4. git init

5. git remote add origin [ 2 에서 복사한 주소 ] 

6. git commit -m "[ 커밋메시지 입력하기 ( ex) initialize my app) ]"

7. git add . (모든 파일을 원격 저장소에 추가)

8. git push origin master (master branch에 올리기)

노마드코더님 클론코딩 진행하면서 알게된 소소한 팁이다.