ITNAI

GitHub Package Firewall은 npm 패키지를 내려받기 전에 기업 보안 정책으로 검사하는 기능입니다. 2026년 10월 20일 공개 미리보기로 출시됐습니다. 기업 정책을 설정한 뒤 개발 PC·CI·코딩 에이전트의 패키지 요청 경로도 바꿔야 합니다. 2026년 10월 21일 확인 기준 대상: GitHub Enterprise Cloud 및 데이터 레지던시 지원 Enterprise Cloud 지원 패키지: npm만 지원 요금: 미리보기 기간 무료, 정식 출시 시 사용량 기반 과금 예정 상태: 공개 미리보기로 기능·조건 변경 가능 목차 어디에서 검사하나요? 정책과 npm 설정 설치가 차단됐을 때 설정 후에도 설치가 안 될 때 자주 묻는 질문 어디에서 검사하나요? 외부 패키지 저장소와 설치 환경 사이에서 패키지 목록 요청과 다운로드를 검사합니다. 도서관에서 책을 빌리기 전에 확인하는 창구처럼 생각하면 쉽습니다. 정책을 켜도 외부 저장소로 직접 향하는 요청은 이 검사 경로를 통과하지 않습니다. 출처: GitHub 출시 안내 정책과 npm 설정 기업 관리자 또는 기업 보안 관리자가 Enterprise → Policies → Package firewall 에서 설정합니다. 검사 항목 확인할 내용 알려진 악성 패키지 Advisory Database 악성 경고 대조 취약점 차단할 최소 심각도 선택 증명 정보 저하 이전 버전에 있던 SLSA 증명이 사라졌는지 검사 새 설치 스크립트 최근 추가된 설치 실행 스크립트 검사 ...

GitHub Push Attribution은 커밋을 push할 때 인증된 사용자를 커밋별로 기록하는 기능 입니다. 커밋 안에 적힌 author·committer 정보와 구분해 실제 push에 사용된 계정을 확인하도록 돕습니다. GitHub는 2026년 10월 12일 이 기능을 발표했으며, 10월 13일 확인 기준 GitHub Enterprise 고객 대상의 제한 공개 프리뷰 입니다. 먼저 알아둘 점 이름·이메일로 표시된 커밋 정보와 인증 계정은 다른 정보입니다. 새 규칙은 committer 이메일을 인증된 pusher의 검증된 이메일과 대조합니다. 프리뷰 참여는 GitHub 담당 account team에 접근을 요청하는 방식입니다. 목차 author·committer·pusher 차이 커밋 정보 확인 방법 Committer must match pusher 규칙 도입 전 점검과 API 확인 자주 묻는 질문 author·committer·pusher는 무엇이 다른가요? 구분 의미 확인하는 정보 author 변경 내용을 처음 작성한 사람 커밋에 기록된 이름·이메일 committer 변경을 적용해 해당 커밋을 만든 사람 커밋에 기록된 이름·이메일 pusher GitHub에 push할 때 인증된 사용자 GitHub가 확인한 push 인증 주체 Git에서 author와 committer는 서로 다를 수 있습니다. 예를 들어 개발자 A가 만든 패치를 개발자 B가 적용하면 A는 author, B는 committer로 기록될 수 있습니다. B가 이를 자신의 계정으로 push하는 상황이라면 pusher도 B가 됩니다. 위 예시는 역할 차이를 설명하기 위한 가상 상황입니다. 실제 조사에서는 이름이 같다는 이유만으로 세 역할을 동일인으로 판단하지 말고, 커밋 메타데이터와 인증 기록을 따로 확인하세요. Git의 이름·이메일 설정은 인증 비밀번호나 토큰이 아닙니다. use...

먼저 결론: GitHub는 2026년 10월 5일 Secret Scanning에 Lovable·Pydantic·Supabase 관련 비밀 유형 5종 탐지를 추가했습니다. 실제 키 유출이 확인되면 코드에서 지우는 것에 그치지 말고, 발급 서비스에서 기존 키를 폐기하고 새 키로 CI·배포 환경을 갱신해야 합니다. API 키와 토큰은 프로그램이 서비스에 접근할 때 사용하는 인증 정보입니다. 비밀번호처럼 보호해야 하며, 저장소에 넣으면 다른 사람이 해당 권한을 사용할 수 있습니다. 이 글은 새로 추가된 탐지 유형, 설정 확인, 유출 경고 대응 을 처음 사용하는 사람도 따라갈 수 있도록 정리했습니다. 발표일: 2026년 10월 5일 · 문서 확인 기준: 2026년 10월 21일 · GitHub.com 공식 문서 기준 목차 10월 변경과 11월 12일 감사 로그 대응 새 탐지 유형 5종 Secret Scanning 활성화 확인 파트너 통보와 사용자 경고 차이 유출 키 폐기·재발급 대응 순서 CI 환경변수와 Actions 점검 자주 묻는 질문 요약과 공식 출처 2026년 10월 변경: Base64 토큰과 11월 12일 감사 로그 대응 발표일은 2026년 10월 20일, 감사 로그 변경 예정일은 2026년 11월 12일입니다. 키 유출 대응과 별도로, 로그를 수집·분류하는 기업 자동화 담당자는 다음 항목을 확인하세요. 적용 구분 변경과 대응 11월 12일 예정 해당 secret_scanning_alert.* 및 secret_scanning_push_protection.bypass 감사 이벤트의 business 값이 기업 표시명에...

핵심 요약: Copilot Memory를 활성화한 사용자가 Agentic Autofix로 코드 스캐닝 경고를 처리하면, 에이전트가 기존 메모리를 수정 문맥으로 참고하고 새 수정 패턴을 다음 작업에 쓸 메모리로 저장할 수 있습니다. 두 기능 모두 공개 미리보기입니다. 생성된 수정안은 테스트와 재검사를 거쳐 사람이 PR을 검토한 뒤 병합해야 합니다. 정보 기준일: 2026년 9월 26일. GitHub의 9월 25일 발표와 공식 문서를 기준으로 작성했습니다. 공개 미리보기의 화면과 제공 범위는 변경될 수 있습니다. 목차 Agentic Autofix와 Copilot Memory 연동 내용 사용 조건과 AI 크레딧 확인 보안 경고에 적용하는 방법 수정 패턴과 메모리 검토·삭제 테스트·CodeQL 재검사·병합 승인 자주 묻는 질문 결론과 공식 자료 Agentic Autofix와 Copilot Memory 연동 내용 Agentic Autofix는 코드 스캐닝 경고를 Copilot에 할당하면 에이전트가 저장소를 살펴보고 수정안을 만든 뒤, 검증을 시도하고 PR을 여는 기능입니다. GitHub는 2026년 9월 25일 Copilot Memory를 활성화한 고객의 Agentic Autofix가 기존 메모리를 참고하고, 새 수정 패턴도 메모리로 저장한다 고 발표했습니다. 예를 들어 저장소에 특정 프레임워크의 입력값 검증 방식이나 함께 수정해야 하는 파일에 관한 사실이 기록돼 있다면, 이후 보안 경고를 처리할 때 그 문맥을 참고할 수 있습니다. 저장된 패턴은 다른 Copilot 기능에도 도움이 될 수 있습니다. 다만 메모리가 있다고 해서 다음 경고가 자동으로 해결되거나 생성된 코드가 안전하다고 보증되는 것은 아닙니다. 구분 일반 Copilot Autofix Agentic Autofix와 Memory 수정 방식 경고에 대한 수정 제안을 제공하며 사용자가 검토·적용 에이전트가 코드를 탐색·수정하고 검증을 ...

핵심 요약: Slack 또는 Microsoft Teams에 GitHub 앱을 설치하고 계정을 연결하면 대화에서 @GitHub 를 호출해 Copilot cloud agent에 조사·계획·코드 작업을 맡기거나 GitHub 이슈와 PR 생성을 요청할 수 있습니다. 2026년 9월 25일 발표된 개선으로 첨부파일과 대화 문맥 활용, 비슷한 이슈 확인, 대화별 모델 선택, 장시간 작업 상태 표시가 강화됐습니다. 기능은 공개 미리보기이며 계정 권한·관리자 정책·AI 사용 예산을 먼저 확인해야 합니다. 정보 기준일: 2026년 9월 26일. GitHub 공식 발표와 Slack·Teams 연동 문서를 기준으로 작성했습니다. 일부 기능은 순차 배포 중이므로 같은 요금제라도 작업 공간에 표시되는 메뉴가 다를 수 있습니다. 목차 Slack·Teams에서 무엇을 할 수 있나 요금제·권한·관리자 설정 확인 Slack 연동 및 사용 방법 Microsoft Teams 연동 및 사용 방법 첨부파일·중복 이슈·모델 선택 활용 작업이 멈추거나 연결되지 않을 때 보안과 PR 승인 점검 자주 묻는 질문과 공식 자료 Slack·Teams에서 무엇을 할 수 있나 GitHub 앱을 연동하면 팀 대화에서 Copilot cloud agent를 호출할 수 있습니다. 대화 내용을 참고해 저장소를 조사하거나 구현 계획을 세우고, 이슈 또는 PR을 만드는 작업으로 이어갈 수 있습니다. 팀원이 같은 대화에서 조건을 보완하거나 에이전트의 작업 방향을 수정할 수도 있습니다. 구분 Slack Microsoft Teams 호출 방법 GitHub 앱과 DM을 열거나 스레드에서 @GitHub 호출 채팅·채널 대화에서 @GitHub 호출 활용 문맥 지원되는 파일·첨부파일·메시지 링크와 대화 내용 인라인 이미지·전달 메시지·채널 및 스레드 대화 결과물 작업 요약과 생성된 이슈·PR 링크 작업 요약과 생성된 이슈·PR 링크 ...

GitHub Copilot Code Review 가 이제 Pull Request(PR)를 검토한 뒤 단순히 의견만 남기는 것을 넘어 실제 승인(Approve) 리뷰까지 제출 할 수 있게 됐습니다. 특히 중요한 변화는 관리자가 허용할 경우 Copilot의 승인이 저장소에서 요구하는 필수 승인 수에 포함될 수 있다는 점 입니다. 예를 들어 PR 병합 전에 승인 1개가 필요한 저장소라면 설정에 따라 Copilot 승인 1개가 그 조건을 충족할 수 있습니다. 하지만 여기서 반드시 구분해야 할 것이 있습니다. Copilot의 승인 평가, 실제 PR 승인, 자동 병합은 서로 다른 기능 입니다. Copilot이 “승인할 준비가 됐다”고 판단했다고 바로 병합되는 것도 아니며, 실제 Copilot 승인이 있어도 상태 검사나 다른 보호 규칙이 남아 있다면 PR은 병합되지 않습니다. GitHub Copilot PR 승인 핵심 요약 발표일: 2026년 9월 1일 현재 상태: Public Preview·공개 미리보기 지원: Copilot Pro·Pro+·Max·Business·Enterprise 모든 Copilot Code Review에 승인 가능 여부 판단이 표시됩니다. 승인 판단만으로는 필수 승인 수를 충족하지 않습니다. 관리자가 허용하면 Copilot이 실제 Approve 리뷰를 제출할 수 있습니다. 설정에 따라 Copilot 승인도 필수 승인 수에 포함될 수 있습니다. 새 커밋이 올라오면 기존 Copilot 승인은 취소될 수 있습니다. 저장소별·조직별·엔터프라이즈별로 승인 기능을 제한할 수 있습니다. 파일 경로를 지정해 Copilot 승인이 인정되는 범위를 제한할 수 있습니다. Copilot 승인과 Auto-merge는 서로 다른 기능입니다. 목차 GitHub Copilot PR 승인에서 무엇이 바뀌었나? 승인 평가와 실제 승인은 무엇이 다른가? Copilot 승인이 필수 승인 수에 포함될까? Copilot 승인과 ...