버그 발견 캠페인
새로운 위반된 보장을 노출할 수 있는 실험을 선택한 후, 실험이 실제로 관찰하는 내용에 따라 계산을 사용합니다. 발견, 재현 및 분류 비용을 계속 확인할 수 있도록 유지하십시오. 속도는 "코드 커버리지가 시간이 지남에 따라 증가해야 함" 및 차단 문제 해결과 함께 나열된 성능 요소 중 하나이며, 유용한 대상은 "테스트 중인 코드에서 좋은 커버리지를 가져야 합니다"; 실행 횟수만으로는 유용한 도달 범위를 설정할 수 없습니다 (OSS-Fuzz 통합, 커버리지, ClusterFuzz 성능, 성능 요소).
현재 역량 파악
실제 대상 리비전, 활성화된 빌드, 하니스 생성자 및 어설션 본문을 읽으십시오. 각 기존 레인이 어떤 입력, 초기 상태, 연산, 효과, 스케줄, 실패 및 구성을 실행하고 관찰할 수 있는지 기록하십시오. 제외 사항과 거부된 케이스를 검사하십시오. 문서화된 빌드/런타임이 적용되는 경우에만 커버리지 또는 도달 가능성 도구를 사용하십시오. Fuzz Introspector는 "C/C++, Python 및 Java로 작성된 프로젝트"에 대한 보고서를 문서화하며, 각각 고유한 빌드 도구가 있으므로 범용 백엔드가 아닙니다 (Fuzz Introspector, 개요 및 빌드 도구 차이점). JavaScript 또는 TypeScript 프로젝트의 경우 JS 레인 인벤토리를 읽으십시오.
검사된 구현이 제공하는 경우 역량으로 계산합니다. 이미 유효-프로그램 생성, 교차 엔진 결과 비교 및 트랜잭션 히스토리를 사용하는 대상의 경우, 동일한 메커니즘을 새 이름으로 추가하는 것은 제안된 발전이 아닙니다. 대신 다루지 않은 상호작용이나 관찰을 선택하십시오: SQLite의 dbsqlfuzz는 "SQL 입력과 데이터베이스 파일을 동시에 변형"하여 "이전 퍼저가 놓친" 결함을 발견했으며, 이는 차원을 함께 검색하는 구체적인 선례입니다. 이는 "독점 퍼즈 테스터"입니다: 공개 도구가 아닌 메커니즘을 차용하십시오 (SQLite 테스팅, §2 및 §4.1.3).
하나의 후보를 실행 가능하게 만들기
프로젝트의 기존 실험 노트에 후보를 설명하고, 서비스나 필수 스키마를 도입하지 마십시오. 이러한 결정을 증거 경로와 함께 유지하십시오. OSS-Fuzz는 대상이 짧은 로컬 실행에서 "적어도 약간의 진행"을 이루도록 요구하며, 재현에는 보고서와 일치하는 빌드가 필요합니다 (OSS-Fuzz 통합, 퍼즈 대상, 재현, 이미지 및 퍼저 빌드):
- 생성자와 공백: 실제 진입점과 기준선에서 생략된 실패 공간.
- 보장과 오라클: governing 계약, 실행 가능한 관찰 및 적법/지원되지 않음/결론 없음 결과.
- 검색: 생성된 값/상태/연산 및 제어된 스케줄, 결함 또는 구성 선택.
- 파일럿: 승인된 경과 시간/작업자/리소스 범위, 재생 자료 및 다음 할당을 정당화할 증거.
작업량을 늘리기 전에 관찰을 설계하십시오. Elle의 추적 가능한 객체는 일반적인 덮어쓰기가 숨기는 종속성을 드러냅니다. 레지스터에 대한 맹목적 쓰기는 "기록을 파괴"하기 때문입니다. 또한 그 추론에는 명시적 한계가 있습니다: 검사기는 건전하며 "완전성 보장에 근접"하고, "우리의 접근 방식은 술어를 무시하고 개별 객체만 다룹니다". 더 많은 비정보 히스토리를 생성하는 생성기는 이러한 한계를 수리하지 않습니다 (Elle, §§3, 4.3 및 9). 일반 계약에는 correctness-oracles을 사용하고, 특정 모델에는 아래 전문가를 사용하십시오.
| 누락된 차원 또는 관찰 | 관련 전문가 |
|---|---|
| 종속 API 객체 및 적법한 연산 시퀀스 | stateful-property-testing |
| 연산 모델이 없고 상태별 오라클 및 경로 재생이 있는 도달 가능한 브라우저 또는 React UI 상태 | ui-state-exploration |
| 필수 상태/효과가 있는 런타임-유효 프로그램 | semantic-program-generation |
| 독립적 실행 비교 또는 정당화된 실행 간 관계 | semantic-differential-testing, metamorphic-testing |
| 계측/검색 메커니즘 또는 보존된 검색 자료 | coverage-guided-fuzzing, corpus-evolution |
| 메모리 접근 진단 또는 제어된 스케줄링 선택 | native-memory-instrumentation, race-detection-campaigns, schedule-exploration |
| 동시 객체 또는 트랜잭션 보장 | linearizability-checking, transactional-history-testing |
| 배포 결함, 제어된 환경 또는 복구 경계 | distributed-fault-testing, deterministic-simulation, crash-consistency-testing |
| 하드 경로 제약 또는 경계 불변식 | symbolic-concolic-execution, bounded-model-checking |
| 리소스 성장, 진행, 빌드 상호작용 또는 수치 정확도 | resource-complexity-testing, liveness-testing, configuration-differential-testing, numerical-oracles |
표는 이 팩의 책임을 안내합니다. 명명된 도구가 대상을 지원한다고 설정하지는 않습니다. 선택된 전문가와 해당 참조만 읽으십시오. harness-sensitivity를 사용하여 새로운 오라클이 대표적인 위반에 도달하고 거부한다는 증거를 얻으십시오. 가능하면 기존 회귀 또는 제어를 통해; SQLite의 돌연변이 테스팅은 "테스트 스위트가 돌연변이를 잡는지 확인"합니다 (SQLite 테스팅, §7.6). 이를 실험에 비례하게 유지하고 반복적인 승인 단계로 만들지 마십시오.
파일럿 증거에서 할당
승인된 범위 내에서 실행하십시오. 대상 코드와 의도된 속성이 실행되는지 확인하고, 사용할 수 없는 경로와 돌연변이가 해결하지 못한 도달 가능한 경로를 구분하십시오. Fuzz Introspector는 각 퍼저의 "정적 도달 가능성 잠재력"을 동적 커버리지와 비교하여 이 구분을 수행합니다. 누락된 생성자, 의미론적 전제 조건 또는 관찰이 제한 요소인 경우 실험을 변경하십시오 (Fuzz Introspector, 개요). 진단을 보려면 파일럿 진단을 읽으십시오.
증거가 더 많은 검색을 정당화할 때 유익한 레인을 확장하십시오. 검색 메커니즘이 다른 보완 레인을 비교하십시오. AFL++는 "모든 보조 퍼저에는 변형이 있어야 합니다"라고 말합니다 (AFL++ 깊이, §3.c 다중 코어 사용). 보편적인 기간이나 코어 수가 아닌 실제 시간, 작업자 및 리소스 제한을 사용하십시오. 런타임 플래그는 전문가에 유지하십시오. 입력당 타임아웃, 캠페인 기간 및 메모리 제한은 서로 다른 제어입니다 (libFuzzer 23.1.0 옵션).
속성 평가 및 의미론적/코드 도달에 대한 원시 카운터, 원시 후보 및 재현된 결과, 중복 및 미지수, 설정/실행/축소/분류 비용을 유지하십시오. 이를 발명된 생산성 점수로 축소하지 마십시오. 비교 주장이 중요한 경우, 일치된 조건과 변동성을 가진 반복 시행을 사용하십시오. FuzzBench는 단일 운 좋은 실행이 아닌 "시행 횟수, 평균, 중앙값, 표준" 편차 및 "도달된 커버리지의 분포"를 보고합니다 (FuzzBench 보고서, 벤치마크별 요약).
요약하기 전에 원래 입력, 시작 상태, 소스/빌드/구성, 계측, 원시 출력 및 재생 선택을 보존하십시오. OSS-Fuzz 테스트케이스는 "대상에 공급된 바이트"를 포함하며, 일부 버그는 보고된 sanitizer에서 "32비트 모드에서만 또는 64비트 모드에서만 재현 가능"합니다. 시드만으로는 완전한 아티팩트가 아닙니다 (OSS-Fuzz 재현, 퍼즈 대상 버그 및 이미지 및 퍼저 빌드). 후보를 failure-reduction 및 evidence-based-triage로 라우팅하십시오. 신뢰할 수 없거나 해결되지 않은 결과를 조용히 세거나 폐기하지 말고 보이게 유지하십시오. ClusterFuzz는 재현의 신뢰성에 따라 필터링하고 "문제가 발생하는 빈도와 조건"에 대한 통계를 유지합니다 (ClusterFuzz 분류, 테스트케이스 필터링 및 충돌 통계).
할당 결정 완료
계속, 차원 변경, 재현/축소/분류 또는 중지를 관찰된 이유와 남은 공간과 함께 기록하십시오. 고원(plateau)은 진단을 동기 부여합니다. 이는 정확성이나 다른 도구가 도움이 될 것임을 증명하지 않습니다. 0개의 발견을 경계 결과로 보존하십시오. 처리되지 않은 후보 대기열은 생성보다는 증거에 다음 트랜치를 사용하는 것을 정당화할 수 있습니다. 커버리지 기반 libFuzzer 또는 AFL 대상의 경우, ClusterFuzz는 대상이 많은 새로운 충돌을 발견하면 "수정하는 것이 성능 분석보다 더 중요할 가능성이 높다"고 조언합니다 (ClusterFuzz 성능, 퍼즈 대상 성능 분석 시기).
테스트된 보장, 실제 예산, 도달된 동작, 증거 경로, 분류된 결과 및 다음 결정을 반환하십시오. 설정된 경우 사용자에게 보이는 효과를 설명하고, 가능한 원인과 입증된 위반을 분리하여 유지하십시오. 작업된 할당 및 기록에 대해서는 캠페인 예시를 읽고, 오해하기 쉬운 지름길에 대해서는 일반적인 실수를 읽으십시오.
호출은 사용자의 기존 범위와 실행 규칙을 유지합니다. 이 자체로 대상 변경, 설치, 클라우드 지출, 프로덕션 결함 주입 또는 외부 게시를 승인하지 않습니다.