{"meta":{"title":"빌드 시스템 보안의 모범 사례","intro":"아티팩트 빌드 및 배포에 사용하는 시스템인 공급망의 끝을 보호하는 방법에 대한 지침입니다.","product":"보안 및 코드 품질","breadcrumbs":[{"href":"/ko/code-security","title":"보안 및 코드 품질"},{"href":"/ko/code-security/tutorials","title":"Tutorials"},{"href":"/ko/code-security/tutorials/implement-supply-chain-best-practices","title":"공급망 모범 사례 구현"},{"href":"/ko/code-security/tutorials/implement-supply-chain-best-practices/securing-builds","title":"빌드 보안"}],"documentType":"article"},"body":"# 빌드 시스템 보안의 모범 사례\n\n아티팩트 빌드 및 배포에 사용하는 시스템인 공급망의 끝을 보호하는 방법에 대한 지침입니다.\n\n## 이 가이드에 대하여\n\n이 가이드에서는 빌드 시스템의 보안을 개선하기 위해 수행할 수 있는 가장 큰 변경 사항을 설명합니다. 각 섹션에서는 보안을 개선하기 위해 프로세스를 변경할 수 있는 사항을 간략하게 설명합니다. 가장 큰 변경 내용이 먼저 나열됩니다.\n\n## 어떤 위험이 있나요?\n\n소프트웨어 공급망에 대한 일부 공격은 빌드 시스템을 직접 대상으로 합니다. 공격자가 빌드 프로세스를 수정할 수 있는 경우 개인 계정 또는 코드를 손상시키지 않고 시스템을 악용할 수 있습니다. 빌드 시스템뿐만 아니라 개인 계정 및 코드를 보호하는 것을 잊지 말아야 합니다.\n\n## 빌드 시스템 보호\n\n빌드 시스템에는 다음과 같은 몇 가지 보안 기능이 있습니다.\n\n1. 빌드 단계는 명확하고 반복 가능해야 합니다.\n\n2. 빌드 프로세스 중에 실행된 내용을 정확히 알고 있어야 합니다.\n\n3. 각 빌드는 새로운 환경에서 시작해야 하므로 손상된 빌드가 향후 빌드에 영향을 주지 않습니다.\n\n   ```\n          GitHub Actions 는 이러한 기능을 충족하는 데 도움이 될 수 있습니다. 빌드 지침은 코드와 함께 리포지토리에 저장됩니다. 직접 호스팅하는 Windows, Mac, Linux 또는 실행기를 포함하여 빌드가 실행되는 환경을 선택합니다. 각 빌드는 새로운 실행기 이미지로 시작하여 공격이 빌드 환경에서 지속되기 어렵게 만듭니다.\n   ```\n\n보안 이점 GitHub Actions 외에도 빈번하고 빠른 빌드를 위해 리포지토리의 git 이벤트를 수동으로, 주기적으로 또는 git 이벤트에서 트리거할 수 있습니다.\n\n```\n          GitHub Actions은 큰 주제이지만, 시작하기 좋은 곳으로는 [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions), [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners) 및 [AUTOTITLE](/actions/using-workflows/triggering-a-workflow)이 있습니다.\n```\n\n## 빌드에 대한 아티팩트 증명 생성\n\n아티팩트 증명을 사용하면 빌드한 소프트웨어에 대해 수정할 수 없는 출처 및 무결성 보장을 생성할 수 있습니다. 따라서 소프트웨어를 사용하는 사용자는 소프트웨어가 빌드된 위치와 방법을 확인할 수 있습니다.\n\n소프트웨어를 사용하여 아티팩트 증명을 생성하는 경우 빌드의 출처를 설정하고 다음 정보가 포함된 암호화 서명된 클레임을 만듭니다.\n\n* 아티팩트와 연결된 워크플로의 링크입니다.\n* 아티팩트의 리포지토리, 조직, 환경, 커밋 SHA, 트리거 이벤트입니다.\n* 출처를 설정하는 데 사용되는 OIDC 토큰의 기타 정보입니다. 자세한 내용은 [OpenID Connect](/ko/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)을(를) 참조하세요.\n\n관련 SBOM(소프트웨어 자료 청구서)을 포함하는 아티팩트 증명을 생성할 수도 있습니다. 빌드에 사용되는 오픈 소스 종속성 목록과 빌드를 연결하면 투명성을 보장하고 소비자가 데이터 보호 표준을 준수하도록 할 수 있습니다.\n\n아티팩트 증명에는 빌드된 아티팩트에 대한 서명과 함께 소스 코드 및 빌드 지침에 대한 링크가 포함됩니다. 아티팩트 증명으로 빌드에 서명하면, 자체 서명 키 자료를 관리할 필요가 없습니다.\nGitHub 는 당사가 운영하는 서명 기관을 통해 이를 처리합니다.\n\n자세한 내용은 [아티팩트 증명을 사용하여 빌드의 출처 설정](/ko/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)을(를) 참조하세요.\n\n## 빌드 서명\n\n빌드 프로세스가 안전해지면 누군가가 빌드 프로세스의 최종 결과를 변조하지 않도록 방지해야 합니다. 이 작업을 수행하는 좋은 방법은 빌드에 서명하는 것입니다. 퍼블릭/프라이빗 암호화 키 쌍을 사용하여 소프트웨어를 공개적으로 배포하는 경우가 많습니다. 프라이빗 키를 사용하여 빌드에 서명하고 소프트웨어 사용자가 사용하기 전에 빌드에서 서명을 확인할 수 있도록 퍼블릭 키를 게시합니다. 빌드의 바이트가 수정되면 서명이 확인되지 않습니다.\n\n빌드에 정확히 서명하는 방법은 작성하는 코드의 종류와 사용자가 누구인지에 따라 달라집니다. 프라이빗 키를 안전하게 저장하는 방법을 알기 어려운 경우가 많습니다. 여기서 한 가지 기본 옵션은 암호화된 비밀을 사용하는 GitHub Actions 것이지만, 해당 GitHub Actions 워크플로에 대한 액세스 권한이 있는 사용자를 제한하기 위해 주의해야 합니다.\n프라이빗 키가 퍼블릭 인터넷(예: Microsoft Azure 또는 HashiCorp Vault)을 통해 액세스할 수 있는 다른 시스템에 저장된 경우 더 고급 옵션은 OpenID Connect를 사용하여 인증하는 것이므로 시스템 간에 비밀을 공유할 필요가 없습니다. 프라이빗 키에 프라이빗 네트워크에서만 접근할 수 있다면, 또 다른 선택지는 자체 호스팅 러너를 사용하는 것입니다 GitHub Actions.\n\n자세한 내용은 [GitHub Actions에서 비밀 사용](/ko/actions/security-guides/encrypted-secrets), [OpenID Connect](/ko/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect),  및 [자체 호스팅 실행기](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)을 참조하세요.\n\n## 변경 불가능한 릴리스 사용\n\n빌드 시스템에서 다른 프로젝트의 릴리스 자산을 사용하거나, 자체 작업을 위한 릴리스를 만드는 경우, 게시 후 변경할 수 없다는 의미에서 해당 릴리스가 변경 불가능(immutable)하도록 보장하여 보안 위험을 줄여야 합니다. 변경 불가능한 릴리스는 공급망 공격과 의도치 않은 변경으로 인한 호환성 파괴를 방지하는 데 도움이 됩니다. 자세한 내용은 [변경이 불가능한 릴리스](/ko/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases)을(를) 참조하세요.\n\n##\n\n```\n          GitHub Actions의 보안을 강화하다\n```\n\n추가로 보안을 GitHub Actions강화하기 위해 수행할 수 있는 여러 가지 추가 단계가 있습니다. 특히 타사 워크플로를 평가할 때는 주의해야 하며 `CODEOWNERS`를 사용하여 워크플로를 변경할 수 있는 사용자를 제한하는 것이 좋습니다.\n\n자세한 내용은 [안전 사용 참조](/ko/actions/security-guides/security-hardening-for-github-actions) 및 [안전 사용 참조](/ko/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions)을(를) 참조하세요.\n\n## 다음 단계\n\n* [엔드투엔드 공급망 보안](/ko/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)\n\n* [계정 보안의 모범 사례](/ko/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)\n\n* [공급망 코드 보안의 모범 사례](/ko/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)"}