Endor Labs AURI Fix, 오픈 소스 종속성 업그레이드의 대안을 추가하다
Endor Labs는 10월 27일 Open Source용 AURI Fix를 발표했다. 이 기능은 종속성 업그레이드가 막혔거나 더 광범위한 변경이 필요한 경우 애플리케이션 수준의 완화 조치를 추가한다. Endor Labs AURI Fix는 또 다른 개입 지점, 즉 취약한 라이브러리를 사용하는 애플리케이션을 제시한다. 회사는 라이브러리를 설치한 상태로 유지하면서도 표적화된 변경을 통해 악용을 차단할 수 있다고 설명했다.
이번 발표는 익숙한 엔지니어링 의사결정을 자동화 워크플로에 담아낸다. 팀은 종속성을 업그레이드해야 할까, 자체 코드를 변경해야 할까, 아니면 일시적 제한을 받아들여야 할까? 각 선택에는 서로 다른 테스트 요구사항과 유지보수 의무가 따른다. 변경을 생성하는 것만으로는 이 결정의 일부만 해결된다.
Black Duck도 같은 날 자체 완화 에이전트를 발표해, 구매자가 자동화된 보안 작업을 평가할 또 다른 기준점을 제공했다. 핵심 긴장은 어느 한 공급업체에 국한되지 않는다. 노출을 신속히 줄이는 것은 팀이 애플리케이션별 보호 조치를 유지할 책임을 지게 할 수 있다. 따라서 보안 설명의 품질은 생성된 코드만큼이나 중요하다.
Endor Labs AURI Fix가 추가하는 기능
이번 출시는 취약한 종속성 자체를 변경하는 방식 외에 완화 선택지를 확장한다.
Endor Labs는 이 제품을 비공개 베타로 제공한다고 설명한다. 애플리케이션 수준 완화 발표에 따르면, 새 기능은 일반적으로 10줄 미만으로 애플리케이션 코드나 구성을 변경한다. 제안된 변경은 여전히 검토 워크플로를 거친다.
여기서 완화와 수정의 구분은 중요하다. 완화는 명시된 조건에서 악용을 차단하는 반면, 수정은 취약한 구성요소 자체를 해결한다. 두 결과 모두 위험을 낮출 수 있지만, 소프트웨어를 운영하는 팀에 서로 다른 의무를 부과한다.
애플리케이션별 보호 조치에는 명확히 정의된 범위가 필요하다. 이는 특정 서비스, 배포 구성 또는 입력 경로를 대상으로 할 수 있다. 누군가 기본 취약점이 해결됐다고 설명할 때마다 그 범위는 계속 드러나야 한다.
고객 입력을 라이브러리에 전달하는 가상의 서비스를 생각해 보자. 해당 입력을 제한하면 서비스에 필요한 동작을 유지하면서도 위험한 작업을 방지할 수 있다. 동일한 라이브러리를 사용하는 다른 서비스는 서로 다른 입력이 필요할 수 있으며, 다른 대응이 요구될 수 있다.
이 사례는 자동화된 완화에 애플리케이션 맥락이 필요한 이유를 보여준다. 패키지 이름과 버전은 잠재적으로 취약한 구성요소를 식별한다. 하지만 그것만으로는 어떤 변경이 주변 제품의 의도된 동작을 유지하는지 판단할 수 없다.
따라서 이 소식은 코드 생성 이상의 의미를 지닌다. 이는 소프트웨어 스택의 어느 계층이 노출을 해소할 책임을 맡게 되는지에 관한 문제다. 종속성 업그레이드는 공유 코드에 수정을 적용하고, 애플리케이션 완화는 애플리케이션 고유의 동작에 더 가까운 곳에 보호를 둔다.
이는 제품 평가에 유용한 구분을 만든다. 구매자는 시스템이 그럴듯한 편집을 제안하는 능력과 그 편집을 정당화하는 능력을 분리해 평가해야 한다. 짧은 제안도 검토자가 보안 효과와 운영상 결과를 이해할 때 가치가 생긴다.
이 구분을 통해 설명한 AURI Fix는 자율적 수정에 대한 일반적 약속보다 평가하기 쉽다. 관련 질문은 제안된 개입이 소유자가 보존해야 하는 동작을 포함해 애플리케이션에 맞는지 여부가 된다.
비공개 베타는 이번 발표에 적절한 경계도 설정한다. 이는 제품 출시와 일부 사용자가 이를 평가할 기회를 확인해 준다. 그러나 엔터프라이즈 소프트웨어 전반에서의 광범위한 운영 도입이나 독립적으로 측정된 신뢰성을 입증하지는 않는다.
개발자에게 즉각적인 의미는 업그레이드가 취약한 패키지 밖의 추가 작업을 유발할 때 활용할 수 있는 선택지가 하나 더 생겼다는 점이다. 보안팀에는 정확한 분류가 필요한 또 다른 결과가 도입된다. 두 집단 모두 구성요소 수정으로 노출이 사라졌는지, 아니면 다른 곳에서 강제된 조건을 통해 사라졌는지 이해해야 한다.
막힌 업그레이드는 애플리케이션 소유자에게 압박을 가한다
애플리케이션 수준 완화는 보안 의사결정을 제품 팀이 소유한 코드와 구성으로 직접 가져온다.
막힌 업그레이드는 상충하는 요구를 제시한다. 보안팀은 취약한 동작이 접근 가능한 범위에서 제거되기를 원한다. 애플리케이션 소유자는 개입이 고객 워크플로, 통합 및 운영 가정을 보존한다는 확신이 필요하다.
이 압박은 쉽게 변경할 수 없는 소프트웨어를 유지하는 팀에 가장 직접적으로 가해진다. 이들의 어려움은 반드시 최신 패키지를 찾는 데 있지 않다. 더 새로운 패키지가 무엇을 바꾸는지, 그리고 그 이후에도 애플리케이션이 올바르게 동작하는지를 확인하는 데 있다.
이 구분은 더 좁은 개입이 매력적인 이유를 설명한다. 팀은 더 광범위한 마이그레이션을 완료하기 전에 로컬 동작 변경을 평가할 수 있다. 그러면 그 로컬 변경은 남은 업그레이드 작업 동안 노출을 관리하는 방법이 된다.
그러나 더 좁은 변경에도 상당한 판단이 필요할 수 있다. 고객이 해당 입력에 의존한다면 허용되는 입력을 제한하는 것은 제품 계약을 바꾼다. 기능을 비활성화하면 애플리케이션이 계속 요청을 처리하더라도 운영 동작이 달라질 수 있다.
따라서 엔지니어링 질문은 수용 가능한 결과에 관한 것이다. 서비스는 어떤 동작을 포기할 수 있는가? 누가 그 결정을 책임지는가? 제한이 실제로 취약한 경로를 포괄한다는 증거는 무엇인가?
AURI Fix 대 업그레이드 비교에서 이러한 질문은 짧은 편집과 대규모 마이그레이션 사이의 오해를 낳는 경쟁 구도를 막는다. 관련 비교에는 검토 노력, 기능적 결과, 배포 요구사항 및 향후 유지보수가 포함된다.
책임도 더 분산된다. 구성요소 유지관리자는 공유 라이브러리에 대한 수정을 배포할 수 있다. 애플리케이션 소유자는 해당 애플리케이션의 사용 방식에 맞춘 보호 조치를 판단해야 한다. 자동화는 그 판단을 도울 수 있지만 소유권을 없애지는 않는다.
이는 보안 리더가 보고에서 요구해야 할 내용을 바꾼다. 해결됨으로 표시된 발견 사항은 설치된 수정과 애플리케이션별 완화를 구별해야 한다. 그렇지 않으면 요약은 조직의 보호가 의존하는 조건을 숨길 수 있다.
릴리스 관리자에게도 또 다른 실질적 결과가 있다. 제안된 변경은 관련 배포가 성공한 이후에만 운영 환경의 노출을 줄인다. 검토 대기열, 테스트 환경 및 릴리스 일정은 여전히 완화 프로세스의 일부다.
따라서 생성된 변경의 개수를 세는 것은 불완전한 진척 지표다. 승인을 기다리는 제안은 배포된 개입과 다른 보안 효과를 지닌다. 기능적 결과를 검토하지 않은 배포된 개입은 또 다른 범주를 제시한다.
이 접근 방식에서는 애플리케이션 지식의 가치가 더 커진다. 팀은 생성된 변경을 평가할 때 이전 설계 결정, 운영 제약 및 테스트 기대치에 접근할 수 있어야 한다. 검색 가능한 엔지니어링 지식 기반은 이러한 맥락을 보존하는 데 도움이 될 수 있다.
장기적 압박은 소프트웨어 아키텍처에도 가해진다. 애플리케이션이 동일한 종속성을 중심으로 반복적으로 로컬 보호 조치를 필요로 한다면, 소유자는 그 관계를 검토해야 한다. 반복되는 완화는 개별 수정으로 해결되지 않는 마이그레이션 문제를 알릴 수 있다.
작은 변경은 유지보수 의무를 이전한다
작은 애플리케이션 변경은 즉각적인 중단을 줄일 수 있지만, 향후 변경에서도 유지해야 하는 보호 조치를 만들 수 있다.
Endor Labs는 서비스 사용 불가 상태를 초래할 수 있는 서비스 거부 취약점의 영향을 받는 Java 애플리케이션을 통해 이러한 상충 관계를 설명한다. 회사의 예시는 관련 경로를 차단하기 위해 Spring Boot Actuator 요청 메트릭을 비활성화한다. 회사는 업그레이드가 완전한 수정이라고 설명한다.
이 사례는 애플리케이션 측 완화를 평가하는 구체적인 방법을 제공한다. 애플리케이션은 노출 감소를 위해 운영 기능을 교환한다. 그 교환의 수용 가능성은 소유자가 해당 기능을 어떻게 사용하는지에 달려 있다.
그 결정은 변경 설명에 포함돼야 한다. 검토자는 보안상의 이점과 포기되는 동작을 모두 이해해야 한다. 차단된 경로만 설명하면 제품 측 결과가 드러나지 않는다.
따라서 AURI Fix 대 업그레이드에 대한 유용한 분석은 배포 이후의 의무를 따른다. 업그레이드는 호환성을 계속 유지해야 하는 새 종속성 버전을 도입한다. 완화는 계속 유지돼야 하는 보호 조건을 도입한다.
후자의 조건은 시간이 지나면서 인식하기 어려워질 수 있다. 나중에 한 엔지니어가 고객 요청을 충족하기 위해 입력 옵션을 복원한다고 상상해 보자. 원래의 제한에 설명이 없다면 그 엔지니어는 자신도 모르게 보안 경계를 제거할 수 있다.
이는 보고된 AURI 사고가 아니라 가상의 실패 방식이다. 이는 완화 조치의 수명이 중요한 이유를 보여준다. 그 안전성은 미래의 유지관리자가 목적을 인식하고 보존할 수 있는지에 부분적으로 달려 있다.
테스트는 그 목적을 표현하는 데 도움이 될 수 있다. 테스트는 단순히 편집의 존재를 확인하는 것이 아니라 필요한 보안 속성을 가시화해야 한다. 그렇지 않으면 이후 리팩터링이 테스트는 유지하면서 중요한 동작을 바꿀 수 있다.
소유권도 같은 이유로 중요하다. 애플리케이션이 변경되거나 종속성 수정이 실용적인 선택지가 되었을 때, 누군가는 완화 조치를 재평가할 책임을 져야 한다. 소유권이 없으면 일시적 개입이 조용히 영구 아키텍처가 될 수 있다.
그렇다고 일시적 보호 조치가 바람직하지 않다는 뜻은 아니다. 이는 유지보수 요구사항이 최초 결정에 포함돼야 한다는 의미다. 팀은 나중에 언제, 왜 이 선택을 재검토해야 하는지도 기록하면서 로컬 제한을 합리적으로 선택할 수 있다.
같은 논리는 구성 변경에도 적용된다. 설정은 소스 코드 패치보다 단순해 보일 수 있지만, 환경에 따라 의미가 달라질 수 있다. 검토자는 보안 결론이 실제로 어떤 배포 구성에 적용되는지 알아야 한다.
따라서 구매자에게 줄 수는 설명적 세부사항으로 남아야 한다. 이는 편집이 영향을 미치는 동작 범위에 대해 거의 말해주지 않는다. 중요한 경계에서의 간결한 변경은 더 크고 일상적인 수정보다 더 많은 검토가 필요할 수 있다.
더 넓은 의미는 완화 자동화가 코드와 함께 의무도 전달해야 한다는 것이다. 가장 강력한 제안은 무엇이 안전해지는지, 사용자에게 무엇이 달라지는지, 유지관리자가 계속 강제해야 하는 것이 무엇인지를 설명한다. 이러한 세부사항이 로컬 개입이 최초 배포 이후에도 유용한 상태로 남는지를 결정한다.
Black Duck은 구매자가 완화 에이전트를 비교하는 방식을 보여준다
경쟁 제품 출시는 검증, 검토 노력 및 운영 결과를 구매의 핵심 질문으로 만든다.
Black Duck은 10월 27일 Signal Agentic Fix를 발표했다. 이 에이전트 기반 완화 워크플로는 스캔, 분류, 수정 생성, 검증 및 사람의 승인을 결합한다. 회사는 오픈 소스 발견 사항에 대한 종속성 업그레이드와 독점 코드에서 발견된 사항에 대한 생성 코드 변경을 설명한다.
Black Duck은 Claude Code 통합이 얼리 액세스에 들어갔으며, 추가 통합도 뒤따를 것이라고 밝혔다. 이러한 제공 범위의 차이는 발표된 기능과 잠재 고객이 즉시 평가할 수 있는 기능을 비교할 때 중요하다.
두 발표는 서로 다른 수정 방식을 강조하지만, 둘 다 인간 검토의 역할을 유지한다. 구매자는 이러한 설명을 비교 성능의 증거로 취급하지 않아야 한다. 어느 발표도 승자를 가리는 독립적인 평가를 제공하지 않는다.
의미 있는 비교는 동일한 애플리케이션과 동일한 취약점에서 시작해야 한다. 각 시스템에는 관련 맥락과 동등한 평가 조건이 제공되어야 한다. 그러면 검토자는 제안된 개입 방식과 명시된 한계를 살펴볼 수 있다.
비교에는 서로 다른 대응이 필요한 발견 사항이 포함되어야 한다. 일부 애플리케이션은 업그레이드를 쉽게 수용할 수 있다. 다른 애플리케이션은 호환성 작업, 로컬 제한 또는 더 광범위한 재설계가 필요하다. 이러한 차이를 제품이 어떻게 처리하는지가 다듬어진 예시보다 더 중요하다.
적합하지 않은 개입을 거부하는 것 역시 가치가 있을 수 있다. 안전한 변경을 확립할 수 없는 이유를 명확히 설명하는 시스템은 검토자에게 유용한 정보를 제공한다. 해결되지 않은 가정을 가진 자신감 있는 제안은 추가 조사 작업을 만들 수 있다.
설명의 품질은 또 다른 경쟁 차원이 된다. 검토자는 전체 조사를 직접 재구성하지 않고도 보안 추론을 평가할 수 있을 만큼 충분한 세부 정보를 필요로 한다. 그 세부 정보에는 가정, 관련 동작, 변경의 예상 효과가 포함되어야 한다.
생성 속도와 함께 검토 부담도 측정할 가치가 있다. 제안이 빠르게 도착하더라도 광범위한 조사가 필요하다면 운영상 이점은 제한적일 수 있다. 명확한 증거를 갖춘 느린 제안은 더 빨리 승인을 통과할 수 있다.
배포 호환성도 비교에 포함되어야 한다. 조직에는 이미 소유권 규칙, 릴리스 통제, 테스트 요구사항이 있다. 수정 제품은 그러한 프로세스가 평가하고 배포할 수 있는 작업을 만들어야 한다.
여기서 일반적인 자동화 홍보는 구체적인 구매 결정으로 바뀐다. 구매자는 도구가 전체 프로세스 전반에서 작업을 줄인다는 증거를 필요로 한다. 그렇지 않으면 더 많은 변경 제안을 생성하는 일이 병목을 검토 단계로 옮길 수 있다.
Endor Labs의 AURI Fix 발표는 이 비교에 또 하나의 구체적인 차원을 더한다. 즉, 의존성 수정의 대안으로서 애플리케이션별 보호를 제시한다. 구매자는 이 옵션이 언제 도움이 되고 언제 피하고 싶은 유지보수 작업을 만드는지 평가할 수 있다.
궁극적으로 경쟁은 구매자에게 제공되는 증거를 개선해야 한다. 비교 가능한 프로덕션 결과는 자율성에 관한 경쟁적 설명보다 더 많은 정보를 제공할 것이다. 그러한 결과가 나오기 전까지는 제품 범위와 입증된 워크플로 적합성이 더 확실한 평가 근거를 제공한다.
연구 수치는 입증된 결과가 아니라 선택지를 설명한다
가능한 완화 조치가 존재한다고 해서 자동화된 변경이 프로덕션에서 안전하게 작동한다는 사실이 입증되는 것은 아니다.
Endor Labs는 자사 연구가 엔터프라이즈 코드베이스에서 도달 가능한 취약점 발견 264,643건을 다뤘다고 말한다. 여기서 도달 가능하다는 것은 애플리케이션 실행이 영향을 받는 코드에 도달할 수 있음을 뜻한다. 해당 기업의 수정 연구 결과에 따르면, 82%에는 애플리케이션 코드 수준의 완화 옵션이 있었다.
이 수치는 신중하게 해석해야 한다. Endor Labs의 기술 설명은 상당한 리팩터링과 테스트를 피할 수 있는 업그레이드를 간단한 업그레이드로 정의한다. 이 조건은 업그레이드 가능성과 애플리케이션 측 옵션을 비교할 때 독자가 추론할 수 있는 범위를 제한한다.
이 수치는 더 폭넓은 개입 방식을 조사할 근거를 제공한다. 하지만 식별된 모든 옵션이 승인되고 배포된 변경으로 이어졌다는 사실을 입증하지는 않는다. 또한 새 제품의 프로덕션 성공률이 독립적으로 검증됐음을 보여주지도 않는다.
제안된 완화 조치와 검증된 배포는 서로 다른 질문에 답한다. 전자는 개입 방식이 가능한 것으로 보이는지를 묻는다. 후자는 구현된 변경이 애플리케이션의 필수 동작을 보존하면서 노출을 차단하는지를 묻는다.
독립 연구는 이 질문들을 분리해서 다뤄야 할 이유를 제공한다. Microsoft 개발자 17명이 참여한 취약점 복구 연구는 DeepVulGuard에서 오탐과 적용할 수 없는 수정 문제가 발견됐다고 보고했다. 이 연구는 다른 시스템을 조사했으므로 AURI의 성능을 입증할 수는 없다.
그 관련성은 방법론에 있다. 유망한 기술 결과는 실제 개발자 워크플로 안에서 평가될 필요가 있다. 맥락, 관련성, 제안된 변경의 사용성은 도구가 의도한 사용자에게 도움이 되는지에 영향을 준다.
이 구분은 보안 증거에도 적용된다. 취약점이 제품에 영향을 주는지 전달하는 문서인 VEX 보고서는 평가 결과를 기록한다. 그 유용성은 해당 평가의 근거가 되는 추론, 범위 및 뒷받침 정보에 달려 있다.
별도의 VEX 일관성 연구는 조사한 도구들 간의 일치도가 낮았으며, 취약점 데이터베이스 차이가 가장 크게 기여했다고 밝혔다. 이 발견은 AURI 시험이 아니라 주변 도구 생태계와 관련된다.
애플리케이션 측 완화의 경우 취약한 컴포넌트가 계속 설치된 상태로 남을 수 있으므로 이 생태계가 중요하다. 서로 다른 도구나 검토자가 보호 조치와 적용 조건을 이해하지 못하면 서로 다른 결론에 도달할 수 있다.
따라서 증거 문서는 검토 가능한 보안 주장으로 취급해야 한다. 영향받는 제품 맥락을 식별하고 결론의 근거를 설명해야 한다. 문서를 자동 생성하는 것만으로는 그 주장의 정확성을 확립할 수 없다.
의사결정 지원 및 변경 생성 시스템으로 설명된 AURI Fix는 이러한 검토의 여지를 남긴다. 이를 범용적인 해결책이라고 부르면 남아 있는 평가 작업이 가려질 것이다. 현재 이용 가능한 증거는 확장된 수정 옵션에 관한 더 좁은 결론을 뒷받침한다.
가장 유용한 회의적 검토는 완전성과 관련된다. 개입 방식이 취약한 동작으로 이어지는 관련 경로를 모두 포괄했는가? 필요한 기능을 보존하는가? 일상적인 애플리케이션 변경 후에도 결론이 유효한가?
이 질문들은 자동화된 수정을 무효화하지 않는다. 그 결과물을 신뢰하는 데 필요한 증거를 정의한다. 또한 공급업체가 코드 생성과 유리한 연구 비율을 넘어 진전을 입증할 구체적인 방법을 제공한다.
베타 결과, 경쟁사 제공 현황 및 증거 수용 여부를 지켜봐야 한다
다음으로 유용한 신호는 실제 고객 워크플로 전반에서 배포된 결과와 검토 가능한 증거에 관한 것이다.
첫 번째 신호는 비공개 베타에서 무엇이 나오는지다. 구매자는 제안된 변경과 검토·배포·유지된 개입 방식을 구분하는 고객 사례를 찾아야 한다. 이러한 단계는 제품이 어디에서 작업을 줄이고 어디에서 인간의 노력이 여전히 필요한지 보여준다.
가장 강력한 사례는 원래의 제약과 선택한 대응 방식을 설명할 것이다. 또한 기능상 영향과 이후의 수정 사항도 식별할 것이다. 성공적인 배포는 독자가 해당 애플리케이션에 적합했던 이유를 이해할 때 더 많은 정보를 제공한다.
서로 다른 애플리케이션에서 반복적으로 수용된 증거는 이 접근 방식의 근거를 강화할 것이다. 누락된 맥락이나 수용할 수 없는 동작 변경 때문에 반복적으로 거부된다면 실질적 범위는 좁아질 것이다. 어느 결과든 구매자가 적합성을 평가하는 데 도움이 된다.
두 번째 신호는 경쟁사 제공 현황이다. Black Duck이 발표한 통합은 추적할 만한 구체적 발전을 제공한다. 구매자는 어떤 워크플로가 제공되기 시작하는지, 그리고 그 워크플로가 기존 검토 및 릴리스 요구사항을 수용하는지 살펴볼 수 있다.
통합이 늘어나면 더 나은 수정을 자동으로 입증하지는 않으면서도 평가 기회는 확대된다. 그 중요성은 사용자가 익숙한 통제 체계 안에서 생성된 변경을 평가할 수 있는지에 달려 있다. 실질적 접근성은 비교를 가능하게 하지만 결과를 대체하지는 않는다.
공급업체가 비교 가능한 지표를 공개한다면 경쟁은 유익한 정보를 제공할 것이다. 승인된 변경, 검토자 노력, 배포 결과 및 이후 수정은 차이를 설명하는 데 도움이 된다. 생성 주변의 작업을 생략하는 광범위한 속도 주장은 통찰을 덜 제공한다.
세 번째 신호는 고객, 보안 검토자 및 다운스트림 도구가 완화 증거를 수용하는지 여부다. 이는 특히 제품이 취약한 컴포넌트를 유지할 때 중요하다. 조직은 왜 해당 배포가 계속 보호되는지 설명해야 한다.
일관된 수용은 애플리케이션 측 개입의 운영상 근거를 강화할 것이다. 반복되는 이견이나 광범위한 수동 설명은 별도의 병목을 드러낼 것이다. 기술적으로 타당한 완화 조치에도 그 범위를 전달할 수 있는 실용적인 방법이 필요하다.
DevOps.com의 오픈 소스 수정 보도는 Futurum 분석가 Mitch Ashley를 통해 그 질문을 포착한다. 그는 에이전트 도입과 증거의 감사 수용을 지켜볼 문제로 지목한다. 이는 향후 도입을 보장하는 것이 아니라 유용한 평가 기준이다.
개발자와 엔터프라이즈 구매자에게 당면 과제는 이러한 결과를 구분해 유지하는 것이다. 생성된 제안, 승인된 변경, 방어 가능한 보안 결론은 각각 증거를 필요로 한다. 공급업체가 이를 별도로 보고할 때 평가는 더 명확해진다.
자체 애플리케이션에서 막힌 취약점부터 시작하고, 일반적인 업그레이드 경로가 여전히 어려운 이유를 문서화하라. 대안적 완화 조치가 어떤 동작을 바꿀지, 어떤 증거가 보호를 입증할지, 그리고 이후 누가 그 보호를 유지할지 물어보라. 그런 다음 전체 검토 및 배포 노력을 업그레이드에 필요한 작업과 비교하라. 짧은 편집이 지속적인 의무를 가리지 않도록 원래의 제약을 계속 드러내라. 이 비교를 활용해 Endor Labs AURI Fix가 실제 병목을 해결하는지 판단하라. 자동화된 변경을 수용하기 전에, 팀은 그것이 노출을 차단하는 이유와 그 보호가 지속되기 위해 무엇이 계속 참이어야 하는지를 모두 설명할 수 있는가?
