Salesforce는 최첨단 모델과 에이전트 하네스가 엔지니어링팀의 처리 속도보다 더 빠르게 악용 가능한 코드 취약점을 찾아낸다고 밝혔습니다. 회사 보안 책임자들은 취약점 발견 이후의 병목으로 어떤 결과에 주의를 기울일지 결정하고, 결과를 어떻게 묶을지 판단하는 일을 꼽았습니다. AI가 취약점 발견을 앞당겼지만 검증과 수정 절차는 그만큼 빨라지지 않았습니다. 검증에는 여전히 환경 접근 권한과 자격 증명, 전문가 판단이 필요하고, 수정 사항은 검토와 배포 절차를 거칩니다. 그 결과 기계 속도의 발견과 사람 속도의 수정 사이에 차이가 생깁니다.

Salesforce는 서로 다른 일정으로 진행하는 두 가지 접근법에 따라 수정 작업을 구성합니다. 전략적 접근은 코드베이스 전반의 시스템 위험을 찾아 구조적 수정으로 해결합니다. 전술적 접근은 서비스별 익스플로잇 체인(특정 서비스를 공격하도록 구성한 단계들의 연쇄)을 검증하고 차단하며, 작업 기간은 몇 시간에서 이따금 몇 주까지 걸립니다. 두 접근은 작업 흐름의 서로 다른 단계에 적용됩니다. 전략적 작업은 검증 단계에서 중복 결함을 제거하고, 보고 단계에서 공통 라이브러리와 취약점의 도달 지점을 기준으로 결과를 묶습니다. 전술적 작업은 체인이 처음부터 끝까지 작동하는지 입증하기 위해 검증과 재공격에 집중합니다.

회사는 심층 보안 점검 결과가 플랫폼 기본 설정, 안전하지 않은 기본 요소, 누락된 검사 같은 소수의 공통 원인에 집중되는 경우가 많다고 밝혔습니다. 잘못된 기본 요소 하나가 수백 또는 수천 건의 결과를 만들 수 있습니다. 공통된 구조적 원인을 수정하면 여러 결과를 한꺼번에 해소할 수 있지만, 각 결과를 따로 수정하면 항목마다 담당자 지정, 검토, 배포와 재시험이 필요합니다. Salesforce는 시스템 차원의 수정이 엔지니어링 책임자에게 자원과 일정을 배정할 수 있는 관리 가능한 구조적 위험 목록을 제공한다고 설명했습니다. 다만 이를 위해서는 명확한 관리 체계와 엔지니어링 담당자가 필요합니다. 취약점 발견을 확장하려면 컴퓨팅 자원이 필요하고, 발견 결과를 처리하려면 조직 설계가 뒷받침돼야 합니다.

전술적 수정은 검증된 다단계 익스플로잇 체인 각각을 별도의 수정 대상으로 삼고, 이후 다시 시험합니다. Salesforce는 가장 높은 중요도의 표적에 대해 실제 운영 전 시험 환경에서 체인을 실행해 정적 분석(코드를 실행하지 않고 검사하는 방식)상 도달 가능해 보일 뿐인 경로와 실제 악용 가능한 경로를 구분합니다. 회사에 따르면 실행 환경 설정, 기능 플래그 또는 미들웨어가 겉으로 드러난 공격 경로를 차단할 수 있습니다. 이 검증을 통과한 신뢰도 높은 결과는 실제 표적에서 작동하는 익스플로잇으로 이어지는 비율이 높았다고 회사는 밝혔습니다. 최근 한 차례 실행에서 파이프라인은 별도로 제출된 버그 바운티 제보와 일치하는 중대 취약점을 찾았습니다. 각 서비스를 시험하도록 설정하려면 시간과 서비스팀의 맥락이 필요하므로 Salesforce는 이 절차를 중요도가 높은 표적에 한정합니다. 서비스팀이 작동하는 컨테이너 또는 컴포즈 정의를 제공하면 검증을 더 자동화할 수 있다고 회사는 설명했습니다.

Salesforce는 어느 한 접근만으로는 빈틈이 생긴다고 주장했습니다. 전략적 수정은 검증된 개별 체인을 놓칠 수 있고, 전술적 수정만 하면 개별 수정이 예산과 엔지니어링 작업 대기열에 부담을 줄 수 있습니다. 회사의 포트폴리오는 장기적인 구조 정비와 공격자가 기다리는 시간에 맞춘 패치를 함께 진행합니다. Salesforce는 보안 책임자에게 시스템 위험을 별도 결과로 분류하고, 취약점 발견을 확대하기 전에 엔지니어링 담당자와 배포 계획을 정하며, 패치 가능 시간을 기준으로 검증된 체인의 우선순위를 정하라고 권고했습니다. 또 분석 엔진을 교체할 수 있도록 하네스를 구성하라고 제안했습니다. 회사는 방법론은 반복 적용할수록 축적되지만 분석 엔진은 교체할 수 있다고 설명하며, 운영자가 개입하는 데 드는 비용과 신뢰성을 팀의 작업 기준에 따라 평가해야 한다고 밝혔습니다.

Salesforce는 최첨단 모델과 에이전트 하네스가 엔지니어링팀의 처리 속도보다 더 빠르게 악용 가능한 코드 취약점을 찾아낸다고 밝혔습니다. 회사 보안 책임자들은 취약점 발견 이후의 병목으로 어떤 결과에 주의를 기울일지 결정하고, 결과를 어떻게 묶을지 판단하는 일을 꼽았습니다. AI가 취약점 발견을 앞당겼지만 검증과 수정 절차는 그만큼 빨라지지 않았습니다. 검증에는 여전히 환경 접근 권한과 자격 증명, 전문가 판단이 필요하고, 수정 사항은 검토와 배포 절차를 거칩니다. 그 결과 기계 속도의 발견과 사람 속도의 수정 사이에 차이가 생깁니다.

Salesforce는 서로 다른 일정으로 진행하는 두 가지 접근법에 따라 수정 작업을 구성합니다. 전략적 접근은 코드베이스 전반의 시스템 위험을 찾아 구조적 수정으로 해결합니다. 전술적 접근은 서비스별 익스플로잇 체인(특정 서비스를 공격하도록 구성한 단계들의 연쇄)을 검증하고 차단하며, 작업 기간은 몇 시간에서 이따금 몇 주까지 걸립니다. 두 접근은 작업 흐름의 서로 다른 단계에 적용됩니다. 전략적 작업은 검증 단계에서 중복 결함을 제거하고, 보고 단계에서 공통 라이브러리와 취약점의 도달 지점을 기준으로 결과를 묶습니다. 전술적 작업은 체인이 처음부터 끝까지 작동하는지 입증하기 위해 검증과 재공격에 집중합니다.

회사는 심층 보안 점검 결과가 플랫폼 기본 설정, 안전하지 않은 기본 요소, 누락된 검사 같은 소수의 공통 원인에 집중되는 경우가 많다고 밝혔습니다. 잘못된 기본 요소 하나가 수백 또는 수천 건의 결과를 만들 수 있습니다. 공통된 구조적 원인을 수정하면 여러 결과를 한꺼번에 해소할 수 있지만, 각 결과를 따로 수정하면 항목마다 담당자 지정, 검토, 배포와 재시험이 필요합니다. Salesforce는 시스템 차원의 수정이 엔지니어링 책임자에게 자원과 일정을 배정할 수 있는 관리 가능한 구조적 위험 목록을 제공한다고 설명했습니다. 다만 이를 위해서는 명확한 관리 체계와 엔지니어링 담당자가 필요합니다. 취약점 발견을 확장하려면 컴퓨팅 자원이 필요하고, 발견 결과를 처리하려면 조직 설계가 뒷받침돼야 합니다.

전술적 수정은 검증된 다단계 익스플로잇 체인 각각을 별도의 수정 대상으로 삼고, 이후 다시 시험합니다. Salesforce는 가장 높은 중요도의 표적에 대해 실제 운영 전 시험 환경에서 체인을 실행해 정적 분석(코드를 실행하지 않고 검사하는 방식)상 도달 가능해 보일 뿐인 경로와 실제 악용 가능한 경로를 구분합니다. 회사에 따르면 실행 환경 설정, 기능 플래그 또는 미들웨어가 겉으로 드러난 공격 경로를 차단할 수 있습니다. 이 검증을 통과한 신뢰도 높은 결과는 실제 표적에서 작동하는 익스플로잇으로 이어지는 비율이 높았다고 회사는 밝혔습니다. 최근 한 차례 실행에서 파이프라인은 별도로 제출된 버그 바운티 제보와 일치하는 중대 취약점을 찾았습니다. 각 서비스를 시험하도록 설정하려면 시간과 서비스팀의 맥락이 필요하므로 Salesforce는 이 절차를 중요도가 높은 표적에 한정합니다. 서비스팀이 작동하는 컨테이너 또는 컴포즈 정의를 제공하면 검증을 더 자동화할 수 있다고 회사는 설명했습니다.

Salesforce는 어느 한 접근만으로는 빈틈이 생긴다고 주장했습니다. 전략적 수정은 검증된 개별 체인을 놓칠 수 있고, 전술적 수정만 하면 개별 수정이 예산과 엔지니어링 작업 대기열에 부담을 줄 수 있습니다. 회사의 포트폴리오는 장기적인 구조 정비와 공격자가 기다리는 시간에 맞춘 패치를 함께 진행합니다. Salesforce는 보안 책임자에게 시스템 위험을 별도 결과로 분류하고, 취약점 발견을 확대하기 전에 엔지니어링 담당자와 배포 계획을 정하며, 패치 가능 시간을 기준으로 검증된 체인의 우선순위를 정하라고 권고했습니다. 또 분석 엔진을 교체할 수 있도록 하네스를 구성하라고 제안했습니다. 회사는 방법론은 반복 적용할수록 축적되지만 분석 엔진은 교체할 수 있다고 설명하며, 운영자가 개입하는 데 드는 비용과 신뢰성을 팀의 작업 기준에 따라 평가해야 한다고 밝혔습니다.