본문으로 건너뛰기

가이드

위험 요소 등록부

위험 요소는 시스템에서 잘못될 수 있는 일을 책임자와 그것을 측정하는 것과 함께 적어 둔 것입니다. 등록부는 릴리스 정책 옆 hazards.yaml 에 있어 프로젝트의 나머지처럼 풀 리퀘스트에서 검토되며, 각 실행은 등록부를 읽은 버전을 기록합니다.

등록부 작성

version: 1
hazards:
  - id: rag-leak
    title: A poisoned document makes the assistant disclose a customer's data
    systems: [support-bot]
    triggers: [a retrieved document carries an instruction]
    exposed: customers whose tickets the assistant reads
    severity: {level: 5, narrative: customer data leaves the company}
    occurrence: {level: 2}
    detectability: {level: 3}
    controls: [retrieved text is quoted, never obeyed]
    residual: Low while the leak ceiling holds; reviewed after every model change.
    owner: [email protected]
    review_by: 2026-12-01
    state: open
    measured_by: [no-leak]
    tested_by: [safety]

각 위험 요소는 measured_by 에 그것을 측정하는 규칙을 적습니다. 이는 release.yaml 의 상한이어야 합니다. max: 규칙이나 max_failures: 규칙입니다(위험 상한). 하한은 무언가가 잘되는 빈도를 측정하므로, 하한으로 측정하는 위험 요소는 거부됩니다. systems 와 tested_by 는 증거를 읽을 시스템과 스위트를 좁히며, 생략하면 모두가 포함됩니다.

심각도, 발생도, 검출도는 고장 모드 및 영향 분석의 1부터 5까지의 서열 등급이며 사람이 매깁니다. Oloproof 는 매겨진 그대로 보여 주고 결코 결합하지 않습니다. 위험 우선순위 수도 잔여 위험 점수도 없습니다. 서열 등급의 곱은 아무도 측정하지 않은 정밀도이기 때문입니다. 잔여 위험은 책임자의 문장입니다. 위험 요소의 state(open, mitigated, accepted, closed)는 팀의 것이며 결정이 아닙니다.

확인하기

oloproof hazards check

확인은 정책에 없는 규칙이나 하한을 적은 위험 요소가 있는 등록부를 거부하고 2 로 종료합니다. 그렇지 않으면 각 위험 요소를 등급, 책임자, 상태와 함께 나열하고, 기한이 지난 검토를 알리며, 각 측정 규칙을 각 시스템의 각 스위트 최신 실행에서 엔진이 결정한 그대로 읽습니다. 측정 규칙이 없는 위험 요소는 미측정으로 표시되고, 어떤 최신 실행도 결정하지 않은 규칙은 이름이 나옵니다. --json 은 같은 보고서를 파이프라인용으로 씁니다.

표시되는 곳

oloproof run 은 실행과 함께 등록부를 기록하고, oloproof push 는 이를 워크스페이스로 보내며, oloproof export 는 로컬 워크벤치가 읽는 번들 옆에 씁니다. Safety and risk 페이지는 각 위험 요소를 상한 위에 등급, 통제 수단, 측정하는 상한의 상태와 함께 보여 주며, 각각 증거로 연결됩니다. 등록부가 바뀌었다가 다시 원래대로 돌아온 경우, 현재 등록부는 마지막으로 쓰인 것이 아니라 가장 최근 실행이 기록한 등록부입니다. 결정 레코드는 그 실행이 기록한 등록부를 지명하고, record verify 는 이를 팀의 말로 보고합니다.

다음 단계

  • 위험 상한 은 위험 요소를 측정하는 규칙을 다룹니다.
  • Gating 은 상한이 릴리스를 막는 방식을 다룹니다.