보안 GitHub 리포지토리를 유지 관리하는 방법

여기서는 GitHub 리포지토리 관리자가 사용할 수 있는 몇 가지 필수 보안 도구 및 기술에 대해 설명합니다.

보안 개발 전략의 중요성

애플리케이션 보안이 중요합니다. 뉴스 서비스는 종종 회사의 시스템과 개인 회사 및 도난당한 고객 데이터의 일부 위반에 대한 이야기를 전달합니다.

그렇다면 보안 개발 전략을 계획할 때 고려해야 할 문제는 무엇인가요? 분명히, 우리는 정보에 액세스 할 수 없어야하는 사람들에게 정보가 공개되지 않도록 보호해야하지만, 더 중요한 것은 정보가 적절한 경우에만 변경되거나 파괴되도록해야합니다.

데이터에 액세스하는 사용자와 데이터에 액세스할 수 있는 올바른 권한이 있는지 제대로 인증해야 합니다. 기록 또는 보관 데이터 또는 로그를 통해 문제가 있을 때 증거를 찾을 수 있어야 합니다.

보안 애플리케이션을 빌드하고 배포하는 데는 여러 가지 측면이 있습니다. 고려해야 할 세 가지 사항은 다음과 같습니다.

• 일반적인 지식 문제가 있습니다. 많은 개발자와 다른 직원은 보안을 이해한다고 가정하지만 그렇지 않습니다. 사이버 보안은 지속적으로 진화하는 분야입니다. 지속적인 교육 및 교육 프로그램은 필수적입니다.

• 코드를 정확하고 안전하게 만들어야 합니다. 코드가 올바르게 생성되고 필요한 기능을 안전하게 구현해야 합니다. 또한 보안을 염두에 두고 기능이 설계되었는지 확인해야 합니다.

• 애플리케이션은 규칙 및 규정을 준수해야 합니다. 코드가 필요한 규칙 및 규정을 준수하는지 확인해야 합니다. 코드를 빌드하는 동안 규정 준수를 테스트한 다음 배포 후에도 주기적으로 다시 테스트해야 합니다.

모든 단계의 보안

보안은 나중에 애플리케이션 또는 시스템에 추가할 수 있는 것이 아닙니다. 보안 개발은 소프트웨어 개발 수명 주기의 모든 단계에 속해야 합니다. 이 개념은 중요한 애플리케이션 및 중요한 또는 극비 정보를 처리하는 애플리케이션에 더욱 중요합니다.

실제로 팀이 개발한 내용에 대한 책임을 묻기 위해 프로세스는 왼쪽으로 이동하거나 개발 수명 주기 초기에 완료해야 합니다. 배포 시 최종 게이트에서 이전 단계로 단계를 이동하면 실수가 줄어들고 개발자가 더 빠르게 이동할 수 있습니다.

애플리케이션 보안 개념은 과거에 개발자에게 중점을 두지 않았습니다. 교육 및 교육 문제 외에도 조직에서 기능의 빠른 개발을 강조했기 때문입니다.

그러나 DevOps 사례가 도입되면 보안 테스트를 파이프라인에 더 쉽게 통합할 수 있습니다. 보안 전문가가 수행하는 작업이 아니라 보안 테스트는 일상적인 배달 프로세스의 일부일 뿐입니다.

전반적으로 재작업 시간을 고려할 때 개발 수명 주기의 앞부분에서 DevOps 사례에 보안을 추가하면 개발 팀이 문제를 더 일찍 파악할 수 있습니다. 문제를 더 일찍 포착하면 실제로 고품질 소프트웨어를 개발하는 데 걸리는 전체 시간을 줄일 수 있습니다.

왼쪽으로 이동하는 것은 프로세스 변경이지만 단일 컨트롤 또는 특정 도구가 아닙니다. 모든 보안을 개발자 중심으로 만들고 개발자에게 보안 피드백을 제공하는 것입니다.

보안 탭 기능

GitHub는 리포지토리 및 조직 전체에서 데이터를 안전하게 유지하는 데 도움이 되는 보안 기능을 제공합니다. 보안 탭을 찾으려면 다음을 수행합니다.

1. GitHub.com 리포지토리의 기본 페이지로 이동합니다.

2. 리포지토리 이름 아래에서 보안을 선택합니다.

보안 탭에서 GitHub 워크플로에 기능을 추가하여 리포지토리 및 코드베이스의 취약성을 방지할 수 있습니다. 이러한 기능은 다음과 같습니다.

• 리포지토리에 파일을 추가하여 프로젝트에서 보안 취약성을 보고하는 방법을 지정할 수 있는 SECURITY.md입니다.
• GitHub에서 리포지토리가 취약한 종속성 또는 맬웨어를 사용하고 있음을 감지할 때 사용자에게 알리는 Dependabot 경고입니다.
• 리포지토리의 보안 취약성에 대한 정보를 비공개로 논의, 수정 및 게시하는 데 사용할 수 있는 보안 권고입니다.
• 코드에서 취약성 및 오류를 찾고, 심사하고, 수정하는 데 도움이 되는 코드 검사입니다.
• 리포지토리에 커밋된 토큰, 자격 증명 및 비밀을 검색하고 푸시 전에 차단할 수 있는 비밀 검사입니다. 푸시 보호 는 공용 리포지토리에서 기본적으로 사용하도록 설정됩니다.

자세한 내용은 GitHub 보안 기능을 참조하세요.

다음으로, 이러한 기능 중 일부를 살펴보고 소프트웨어 개발 수명 주기의 모든 단계에서 보안 및 운영 책임을 분산하는 방법을 알아봅니다.

SECURITY.md 보안 정책 전달

GitHub의 커뮤니티 혜택은 상당하지만 잠재적인 위험도 수반합니다. 누구나 버그 수정을 공개적으로 제안할 수 있다는 사실은 특정 책임과 함께 제공됩니다. 가장 중요한 것은 기본 버그를 수정하기 전에 보안 악용으로 이어질 수 있는 정보의 책임 있는 공개입니다. 개발자는 보안 문제를 보고하거나 해결하기 위해 리포지토리의 루트에 있는 파일 SECURITY.md을 찾아 책임감 있게 문제를 공개합니다. 이 파일에 지침을 제공하면 궁극적으로 이러한 중요한 문제를 신속하게 해결할 수 있습니다.

자세한 SECURITY.md내용은 리포지토리에 보안 정책 추가를 참조하세요.

GitHub 보안 공지

GitHub Security Advisories를 사용하면 리포지토리 유지 관리자가 프로젝트의 보안 취약성을 비공개로 논의하고 수정할 수 있습니다. 리포지토리 유지 관리자는 수정에 대해 공동 작업한 후 보안 권고를 게시하여 보안 취약성을 프로젝트 커뮤니티에 공개적으로 공개할 수 있습니다. 리포지토리 유지 관리자는 보안 권고를 게시하여 커뮤니티에서 패키지 종속성을 더 쉽게 업데이트하고 보안 취약성의 결과를 연구할 수 있도록 합니다. GitHub는 게시된 권고를 CVE(Common Vulnerabilities and Exposures) 목록에 저장합니다. 이 목록은 나열된 취약성이 있는 소프트웨어를 사용하는 영향을 받는 리포지토리에 자동으로 알리는 데 사용됩니다. 자세한 내용은 리포지토리 보안 권고 정보를 참조하세요.

.gitignore를 사용하여 리포지토리에서 민감한 파일을 제거하세요.

개발자는 커밋에 포함된 파일을 쉽게 간과할 수 있습니다. 이러한 간과된 파일은 중간 빌드 파일과 같이 무해한 경우가 있습니다. 그러나 누군가가 실수로 중요한 데이터를 커밋할 위험이 항상 있습니다. 예를 들어 누군가가 악의적인 행위자가 사용할 수 있는 API 키 또는 프라이빗 구성 데이터를 커밋할 수 있습니다. 이러한 위험을 방지하는 한 가지 방법은 파일을 빌드하고 유지 관리하는 .gitignore 것입니다. 이러한 파일은 git 명령줄 유틸리티와 같은 클라이언트 도구에 경로와 패턴을 무시하도록 지시하여 커밋을 위한 파일을 집계합니다.

다음 샘플에서는 파일을 무시하기 위한 몇 가지 일반적인 사용 사례를 보여 줍니다.

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

리포지토리에 여러 .gitignore 파일이 포함될 수 있습니다. 설정은 부모 디렉터리에서 상속되며 새 파일의 .gitignore 재정의 필드가 해당 폴더 및 하위 폴더에 대한 부모 설정보다 우선합니다. 루트 .gitignore 파일을 유지 관리하는 것은 상당한 노력이 필요하지만, 특정 요구 사항이 있는 프로젝트에서 부모와 별도로 관리하기 쉬운 파일, 예를 들어 무시.gitignore 안 되는 파일과 같은 경우에는 프로젝트 디렉터리에 파일을 추가하는 것이 도움이 될 수 있습니다.

자세한 내용은 .gitignore파일 무시를 참조하세요. .gitignore의 다양한 플랫폼용으로 제공되는 스타터 파일 컬렉션도 확인해 보세요.

리포지토리에서 중요한 데이터 제거

기여자가 중요한 데이터를 커밋하지 않도록 돕는 데 파일이 유용할 수 있지만, 이는 .gitignore 강력한 권고사항일 뿐입니다. 개발자는 충분한 동기가 있다면 .gitignore 파일의 제한을 우회하여 파일을 추가할 수 있습니다. 또한 .gitignore 파일 구성을 충족하지 않아서 파일이 의도치 않게 포함될 수도 있습니다. 프로젝트 참가자는 항상 리포지토리 또는 해당 기록에 포함되지 않아야 하는 데이터를 포함하는 커밋을 경계해야 합니다.

브랜치 보호 규칙

분기 보호 규칙을 만들어 하나 이상의 분기에 특정 워크플로를 적용할 수 있습니다. 예를 들어, 보호된 분기에 병합된 모든 끌어오기 요청에 대해 승인 검토 또는 상태 확인 통과를 요구할 수 있습니다.

브랜치를 보호하는 워크플로를 사용하면 다음을 수행할 수 있습니다.

• 빌드를 실행하여 코드 변경 내용을 빌드할 수 있는지 확인합니다.
• linter를 실행하여 내부 코딩 규칙에 대한 오타 및 준수를 확인합니다.
• 자동화된 테스트를 실행하여 코드의 동작 변경 내용을 확인합니다.
• 등등

끌어오기 요청의 필수 검토자

코드를 중요한 분기에 병합하기 전에 검토를 요구하여 리포지토리 보안을 향상시킬 수 있습니다. 필요한 검토자는 품질, 보안 및 책임을 적용하는 데 도움이 됩니다.

필요한 검토자를 구성하려면 다음을 수행합니다.

1. GitHub의 리포지토리로 이동합니다.
2. 리포지토리 이름 아래에서 [설정>분기]를 클릭합니다.
3. 보호하려는 분기 옆에 있는 규칙 추가 를 클릭하거나 기존 규칙을 편집합니다.
4. 병합하기 전에 끌어오기 요청 검토 필요를 선택합니다.
5. 필요에 따라 다음을 확인합니다.
   • 코드 소유자의 검토 필요
   • 새 커밋이 푸시될 때 부실 끌어오기 요청 승인 해제
   • 마지막 푸셔가 아닌 다른 사용자의 승인 필요

관리자 권한 없이는 필요한 검토를 무시할 수 없습니다. 병합되기 전에 다른 기여자 또는 지정된 코드 소유자가 제안된 변경 내용을 검토하도록 합니다.

자세한 내용은 보호된 분기 정보를 참조하세요.

CODEOWNERS 파일 추가

리포지토리에 CODEOWNERS 파일을 추가하여 개별 팀 구성원 또는 전체 팀을 리포지토리의 경로에 코드 소유자로 할당할 수 있습니다. 그런 다음 이러한 코드 소유자는 구성된 경로의 파일 변경 내용에 대한 끌어오기 요청 검토에 필요합니다.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

리포지토리의 루트나 docs 또는 .github 폴더에 CODEOWNERS 파일을 만들 수 있습니다.