보안 GitHub 리포지토리를 유지 관리하는 방법
여기서는 GitHub 리포지토리 관리자가 사용할 수 있는 몇 가지 필수 보안 도구와 기술을 설명합니다.
참고 항목
다음 콘텐츠는 보안 코드 작성의 기본 사항을 다루지 않고 GitHub 리포지토리 내에서 사용할 중요한 보안 고려 사항, 도구 및 기능을 다룹니다.
보안 개발 전략의 중요성
애플리케이션 보안은 중요합니다. 뉴스 서비스에서는 회사 시스템의 일부 침해, 프라이빗 회사 및 고객 데이터의 도난에 대한 기사를 자주 전달합니다.
그렇다면 보안 개발 전략을 계획할 때 고려해야 할 문제는 무엇입니까? 정보에 접근해서는 안 되는 사람에게 정보가 공개되지 않도록 보호하는 것도 중요하지만, 더 중요한 것은 적절한 경우에만 정보가 변경되거나 파기되도록 해야 한다는 것입니다.
데이터에 액세스하는 사용자를 제대로 인증하고 이와 같은 사용자에게 올바른 액세스 권한이 있는지 확인해야 합니다. 기록 데이터 또는 보관 데이터나 로그를 통해 무언가 잘못되었을 때 증거를 찾을 수 있어야 합니다.
보안 애플리케이션 빌드 및 배포에는 다양한 측면이 있습니다. 고려해야 할 세 가지 사항은 다음과 같습니다.
일반적인 지식 문제가 있습니다. 많은 개발자와 기타 직원은 보안에 대해 잘 알고 있다고 여기지만 실제로는 그렇지 않습니다. 사이버 보안은 계속 발전하는 분야입니다. 지속적인 교육 및 학습 프로그램이 필수적입니다.
코드를 올바르고 안전하게 작성해야 합니다. 코드를 올바르게 작성해야 하고 필요한 기능을 안전하게 구현해야 합니다. 또한 기능이 보안을 염두에 두고 설계되었는지 확인해야 합니다.
애플리케이션이 규칙과 규정을 준수해야 합니다. 코드가 필요한 규칙과 규정을 준수하는지 확인해야 합니다. 코드를 작성할 때 규정 준수 여부를 테스트하고 배포 후에도 주기적으로 다시 테스트해야 합니다.
모든 단계의 보안
보안은 나중에 애플리케이션이나 시스템에 추가할 수 있는 것이 아닙니다. 보안 개발은 소프트웨어 개발 수명 주기의 모든 단계에 포함되어야 합니다. 이 개념은 중요한 애플리케이션과 중요하거나 기밀 정보를 처리하는 애플리케이션에 더욱 중요합니다.
실제로 팀이 개발 내용에 대해 책임을 지도록 하려면 프로세스가 개발 수명 주기에서 왼쪽으로 이동하거나 더 일찍 완료되어야 합니다. 배포 시 최종 게이트의 단계를 이전 단계로 이동하면 실수가 줄어들고 개발자가 보다 신속하게 이동할 수 있습니다.
과거에는 애플리케이션 보안 개념이 개발자의 관심사가 아니었습니다. 교육과 학습 문제 외에도 조직에서 기능의 신속한 개발을 강조했기 때문입니다.
그러나 DevOps 방식을 도입하면서 보안 테스트를 파이프라인에 통합하기가 쉬워졌습니다. 보안 테스트는 보안 전문가가 수행하는 작업이라기보다 일상적인 제공 프로세스에 포함되어야 합니다.
전반적으로 재작업 시간을 고려할 때 개발 수명 주기 초기에 DevOps 방식에 보안을 추가하면 개발 팀이 문제를 더 일찍 발견할 수 있습니다. 문제를 조기에 발견하면 실제로 고품질 소프트웨어를 개발하는 데 걸리는 전체 시간을 줄일 수 있습니다.
왼쪽으로 이동하는 것은 프로세스 변경이지만 단일 제어나 특정 도구는 아닙니다. 이는 모든 보안을 더욱 개발자 중심으로 만들고 개발자에게 보안 피드백을 제공하는 것입니다.
보안 탭 기능
GitHub는 리포지토리와 조직 전체에서 데이터를 안전하게 유지하는 데 도움이 되는 보안 기능을 제공합니다. 보안 탭을 찾으려면:
GitHub.com 리포지토리의 기본 페이지로 이동합니다.
리포지토리 이름 아래에서 보안을 선택합니다.
보안 탭에서 GitHub 워크플로에 기능을 추가하여 리포지토리와 코드베이스의 취약성을 방지할 수 있습니다. 다음과 같은 기능이 있습니다.
- 보안 정책에서 리포지토리에
SECURITY.md파일을 추가하여 프로젝트의 보안 취약성을 보고하는 방법을 지정할 수 있습니다. - Dependabot 경고는 GitHub가 리포지토리가 취약한 종속성 또는 맬웨어를 사용하고 있음을 감지할 때 알립니다.
- 보안 권고 사항은 리포지토리의 보안 취약성에 대한 정보를 비공개로 토론, 수정 및 게시하는 데 사용할 수 있습니다.
- 코드 검사는 코드의 취약성과 오류를 찾아 심사하고 수정하는 데 도움이 됩니다.
자세한 내용은 GitHub 보안 기능을 참조하세요.
참고 항목
맬웨어에 대한 Dependabot 경고 권고는 현재 베타 버전이며 변경될 수 있습니다. GitHub에서 검토한 권고만 Dependabot 경고를 트리거합니다.
다음으로 이러한 기능 중 일부를 살펴보고 소프트웨어 개발 수명 주기의 모든 단계에서 보안 및 운영 책임을 분산하는 방법을 알아봅니다.
SECURITY.md를 사용하여 보안 정책 전달
GitHub의 커뮤니티 이점은 상당하지만 잠재적 위험도 있습니다. 누구나 버그 수정을 공개적으로 제안할 수 있으므로 특정한 책임이 따릅니다. 근본적인 버그가 수정되기 전에 보안 익스플로잇을 초래할 수 있는 정보를 책임감 있게 공개하는 것이 가장 중요합니다. 보안 문제를 보고하거나 해결하려는 개발자는 관련 정보를 책임감 있게 공개하기 위해 리포지토리 루트에 있는 SECURITY.md 파일을 찾아봅니다. 이 파일에 지침을 제공하면 궁극적으로 이러한 중요한 문제의 해결 속도가 빨라집니다.
SECURITY.md에 대한 자세한 내용은 Adding a security policy to your repository(리포지토리에 보안 정책 추가)를 참조하세요.
GitHub 보안 공지
GitHub 보안 공지를 사용하면 리포지토리 유지 관리자가 프로젝트의 보안 취약성을 비공개로 논의하고 수정할 수 있습니다. 리포지토리 유지 관리자는 수정 작업에 협력한 후 보안 공지를 게시하여 프로젝트 커뮤니티에 보안 취약성을 공개적으로 공개할 수 있습니다. 보안 권고를 게시함으로써 리포지토리 관리자는 커뮤니티가 패키지 종속성을 업데이트하고 보안 취약성의 결과를 조사하는 것을 더 쉽게 만듭니다. GitHub는 CVE(Common Vulnerability 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에 대한 자세한 내용은 Ignoring files(파일 무시)를 참조하세요. gitignore 리포지토리에서 다양한 플랫폼에 제공되는 시작 .gitignore 파일 컬렉션도 확인해 보세요.
리포지토리에서 중요한 데이터 제거
.gitignore 파일은 참여자가 중요한 데이터를 커밋하지 않도록 하는 데 유용할 수 있지만, 강한 제안에 불과합니다. 개발자는 충분한 동기가 있는 경우 이 문제를 해결하여 파일을 추가할 수 있으며 때로는 파일이 .gitignore 파일 구성을 충족하지 않기 때문에 누락될 수도 있습니다. 프로젝트 참가자는 항상 리포지토리나 해당 기록에 포함되어서는 안 되는 데이터가 포함된 커밋을 주의 깊게 살펴봐야 합니다.
Important
어느 경우에든 GitHub에 커밋된 모든 데이터는 손상되었다고 간주해야 합니다. 단순히 커밋을 덮어쓰는 것만으로는 향후 데이터에 액세스할 수 없도록 보장하는 데 충분하지 않습니다. GitHub에서 중요한 데이터를 제거하는 방법에 대한 자세한 안내는 Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)를 참조하세요.
분기 보호 규칙
하나 이상의 분기에 특정 워크플로를 적용하기 위해 분기 보호 규칙을 만들 수 있습니다. 예를 들어, 보호된 분기에 병합된 모든 끌어오기 요청에 대해 승인 검토 또는 상태 확인 통과를 요구할 수 있습니다.
분기를 보호하는 워크플로를 사용하여 다음을 수행할 수 있습니다.
- 빌드를 실행하여 코드 변경 사항이 빌드될 수 있는지 확인
- Linter를 실행하여 오타 및 내부 코딩 규칙 준수 여부 확인
- 자동 테스트를 실행하여 코드의 동작 변경 확인
- 등
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 파일을 만들 수 있습니다.