실무에서 무너지는 것
- 과거 결정이 리포지토리에 연결되지 않아 같은 무해한 findings가 반복해서 돌아옵니다.
- 스캔 뒤에 지속되는 팀 상태가 없기 때문에 다른 개발자가 같은 이슈를 서로 다르게 보게 됩니다.
- 리더십은 findings, suppression, 진행 상황의 연속된 이야기 대신 스냅샷만 보게 됩니다.
팀 메모리
한 번의 스캔 그 이상이 필요한 팀을 위한 공유 보안 메모리
모든 스캔이 0에서 다시 시작하면 보안 워크플로는 무너집니다. Oryon은 연결된 리포지토리를 공유 메모리로 취급해 suppression, findings, 프로젝트 이력이 개발자와 미래 스캔 전반에 걸쳐 유지되도록 합니다.
공유 보안 메모리
보안에 공유 메모리가 없으면 무엇을 잃는가
repo가 연결되면 대량 동기화되는 리포지토리 연결 findings와 dependency vulnerabilities.
- 팀이 suppression과 scan 이력이 한 번의 로컬 세션을 넘어 유지되기를 원할 때.
- dashboard가 기본 스캐너가 아니라 공유 메모리 역할을 하길 원할 때.
- 개발자 워크플로와 팀 차원의 후속 조치 사이의 연결을 더 촘촘히 만들고 싶을 때.
메모리가 중요한 이유
보안에 공유 메모리가 없으면 무엇을 잃는가
작동 방식
로컬 스캔이 어떻게 팀의 공유 상태가 되는가
01
리포지토리를 프로젝트에 연결
워크플로 안에서
확장 프로그램은 리포지토리를 식별하고 프로젝트에 연결해 이후 업로드가 같은 팀 컨텍스트에 속하도록 합니다.
무엇이 남는가
이것이 고립된 로컬 스캔을 개별 세션을 넘어 유지되는 연속성 계층으로 바꾸는 지점입니다.
02
findings와 dependency 상태를 대량 동기화
워크플로 안에서
연결되면 findings와 dependency vulnerabilities를 chunk 단위로 업로드해 dashboard가 해당 리포지토리의 최신 scan 상태를 반영하도록 할 수 있습니다.
무엇이 남는가
이로써 스캔이 어디서 실행되었는지를 바꾸지 않고도 엔지니어링과 AppSec가 같은 공유 기준점을 갖게 됩니다.
03
suppression과 이력을 다음으로 이어 가기
워크플로 안에서
공유 suppression과 scan 이력은 리포지토리에 연결된 상태로 남아 이후 스캔이 그 컨텍스트를 처음부터 다시 만드는 대신 재사용하도록 합니다.
무엇이 남는가
이것이 일회성 스캐너와 팀이 지속적으로 운영할 수 있는 시스템의 차이입니다.
적합한 경우
공유 보안 메모리가 실제 이점이 되는 경우
다음에 해당하면 Oryon을 선택하세요
- 팀이 suppression과 scan 이력이 한 번의 로컬 세션을 넘어 유지되기를 원할 때.
- dashboard가 기본 스캐너가 아니라 공유 메모리 역할을 하길 원할 때.
- 개발자 워크플로와 팀 차원의 후속 조치 사이의 연결을 더 촘촘히 만들고 싶을 때.
다른 모델이 더 나은 경우
- 첫 번째 스캔 이후 repo 연결 연속성이 필요하지 않을 때.
- 공유 suppression과 scan 이력이 운영 모델상 중요하지 않을 때.
- 로컬 우선 계층을 유지하기보다 스캐닝 엔진 자체를 중앙화하고 싶을 때.
FAQ
첫 번째 스캔 이후의 연속성을 원할 때 팀이 묻는 질문
- 정확히 무엇이 공유 메모리가 되나요?
- 공유 계층에는 연결된 프로젝트 상태, findings, dependency vulnerabilities, suppression, 리포지토리에 연결된 scan 이력이 포함될 수 있습니다.
- 개발자는 여전히 로컬에서 작업하나요?
- 네. 공유 보안 메모리는 로컬 우선 워크플로를 대체하지 않습니다. 로컬 스캔이 끝난 뒤에도 유용해야 할 상태를 보존할 뿐입니다.
- 이것이 반복 리뷰 작업을 줄이는 데 왜 도움이 되나요?
- 팀이 더 이상 같은 무해한 findings를 반복해서 다시 판단하지 않아도 되고, 리포지토리를 다시 스캔할 때마다 이전 스캔의 컨텍스트를 잃지 않기 때문입니다.