앱이 QA를 통과하고 프로덕션에 배포되고, 모든 사람들이 다음 단계로 넘어가면, 의존성 문제가 외부에서 나타나거나, 주의하지 않게 구성 변경으로 노출된 엔드포인트가 내부 엔드포인트로 생각되었던 경우, 또는 실시간 업데이트에서 잘못된 자바스크립트 번들을 장치에 푸시하는 경우가 발생합니다. 그들은 앱 취약점 스캔이 스캐너 문제가 아니라 라이프 사이클 문제라는 것을 발견합니다.
구매하고 "스캔" 버튼을 클릭하는 것이 어려운 것은 아닙니다. 어려운 것은 취약점을 일찍 발견하는 시스템을 구축하는 것이고, 배포 후에도 계속 실행되며, 발견된 결과를 수정하기 전에 개발자가 경고를 무시하기 시작하는 것을 막는 것입니다. CapacitorJS와 Electron 스택에서 앱은 배포 후에도 웹 레이어 업데이트, 콘텐츠 변경, 원격 구성으로 변경될 수 있으므로 이 문제는 더 복잡해집니다.
A robust setup은 code, 의존성, 컨테이너, 실행 중인 서비스 및 사용자의 장치에 바이너리가 이미 설치된 후 배포하는 번들을 포함해야 합니다. 또한 엔지니어의 작업 방식에 맞춰져야 합니다. 스캔이 느려지거나 노이즈가 많거나 pull request 및 릴리스 워크플로우와 분리된 경우 pipe라인이 우회될 것입니다. broader 애플리케이션 위험 평가 프로세스통합표
Proactive Vulnerability Scanning의 중요성
- 스캔이 의미가 있으려면 remediation이 포함되어야 합니다
- 각각의 스캐너가 실제로 무엇을 잘하는지
- Why Proactive Vulnerability Scanning Matters
- CI/CD 취약성 PIPELINE 빌드
- 결과 해석 및 수정 우선순위
- 실시간 업데이트와 함께 빠른 수정
- 체크리스트에서 문화로
Why Proactive Vulnerability Scanning Matters
금요일 오후, 약한 스캔 프로그램이 노출되는 시간입니다. 새로운 의존성 CVE가 발생하면, 보안 팀은 영향을 받은 앱을 확인하고자 합니다. 그러나, 아직 지난 달의 보고서를 가지고 있는 팀만이 정확한 정보를 알 수 있습니다. 모바일 및 데스크톱 팀은 추가적인 문제를 가지고 있습니다. 백엔드가 수정된 후에도, 클라이언트는 사용자가 업데이트하거나 팀이 제어된 방법으로 프로덕션에서 라이브 콘텐츠를 패치할 수 있는 때까지 취약한 code 상태로 유지될 수 있습니다.
이것이为什么 프로액티브 스캔이 중요한 이유입니다. 팀은 현재의 인벤토리, 각 발견의 명확한 책임자, 그리고 발견부터 검증된修정까지의 더 빠른 경로를 얻을 수 있습니다. 또한, Capacitor 및 Electron 앱의 위험은 출시일 이후에도 계속됩니다. 앱이 웹 자산, 원격 구성, 플러그인, 또는 라이브 업데이트 통해 동작을 변경할 수 있기 때문입니다. 하이브리드 및 라이브 업데이트 앱에 대한 공식적인 앱 위험 평가 일반적으로, 팀은 스캔기를 실행하는 것이 어려운 것이 아니라, 현재 프로덕션에서 노출된 것을 증명하는 것이 어려운 것을 발견합니다.
스캔은 만약 remediation이 내장되지 않았다면 의미가 없습니다.
보고서를 PDF로 내는 스캐너는 백로그를 만듭니다, 보호를 제공하지 않습니다. 작동하는 프로그램은 발견을 서비스 책임자와 연결하고, 충분한 컨텍스트를 포함한 티켓을 열고, 수정이 적용된 후 재 테스트를 기록합니다. 만약 이 전달이 누락된다면, 팀은 보고서를 무시하거나, 이슈가 실제로 존재하는지 여부에 대해 일주일 동안 논쟁을 벌일 것입니다.
간단한 규칙을 사용하세요.
실용적인 규칙: 발견이 assign, fixed, 및 verified되지 않으면, 그것은 보안 모니터링이 아닌 위험 감소입니다.
워크플로가 전체 생애주기를 커버해야 합니다. 자산의 범위를 정의하세요. code, 의존성, 빌드 아티팩트 및 실행 중인 서비스를 스캔하세요. 취약점의 취약성과 노출을 기준으로 분류하세요. 시간이 허용되는 경우 일반 배포 경로를 사용하여 수정하세요. 그렇지 않으면, 특히 스토어 릴리스 외부에서 웹 code을 업데이트할 수 있는 앱의 경우, 후속 릴리스 경로를 사용하세요. 그런 다음 노출이 사라졌는지 확인하기 위해 다시 스캔하세요.
기다리는 것은 금전적으로 빠르게 비싸집니다.
반응형 청소는 예측 가능한 방식으로 엔지니어링 시간을 소비합니다. 개발자들은 오래된 code에 다시 뛰어들고 있습니다. 보안 팀은 여러 도구를 통해 동일한 문제를 다시 확인합니다. 릴리스 매니저들은 이미 릴리스 창이 밀려드는 경우 예외 승인에 시작합니다. 결과는 잡음, 지연, 그리고 매우 적은 자신감입니다.
예방적 스캔은 경제학을 바꿉니다. 발견은 해당 코드를 수정한 시점에 더 가까운 곳에서 나타납니다. 책임은 명확합니다. 프로덕션 노출은 더 쉽게 답변할 수 있습니다. 그리고 라이브 앱이 빠른 후배포修정을 필요로 할 때, 팀은 이미 영향을 받은 레이어를 알고 patch가 스토어 제출, 서버 사이드 변경, 또는 제어된 라이브 업데이트 필요 여부를 알고 있습니다.
앱 취약성 스캔의 네 가지 기둥
일반적인 앱 취약점 스캔은 네 가지 카테고리가 협력하여 작동하는 것을 포함합니다. 취약점을 식별하는 데 사용하는 각 방법은 다른 부분의 위험을 식별합니다. 단일 스캐너 유형에만 의존하면 하나의 진실만 얻을 수 있고 여러 가지 blind spot이 발생합니다.
각 스캐너가 실제로 무엇을 잘하는지
SAST 소스 코드 code, 바이트코드, 또는 컴파일된 아티팩트를 읽어도 앱을 실행하지 않습니다. 개발자가 code을 변경하는 동안 빠른 feedback를 얻을 수 있는 것이 가장 좋습니다. SonarQube와 Semgrep는 pull request와 CI에 잘 적합하여 일반적으로 선택됩니다.
DAST 외부에서 실행 중인 앱을 공격합니다. 인증 오류, 잘못된 헤더, 서버 동작이 깨진 경우, 노출된 경로, 요청이 전체 스택을 통과할 때만 나타나는 문제를 찾습니다. OWASP ZAP과 Burp Suite는 익숙한 옵션입니다.
IAST 런타임에 더 가까운 곳에 위치하고 일반적으로 인스트루먼테이션 또는 에이전트를 통해 내부 시각화를 라이브 실행과 결합합니다. 이는 '이 패턴이 위험해 보인다'와 '이 요청 경로가 취약점이 될 수 있다' 사이의 간격을 kapat할 수 있습니다.
SCA 의존성树 내의 세 번째-party 패키지 및 알려진 문제를 추적합니다. 대부분의 현대 팀은 소스 코드만으로 스캔하는 것보다 즉시 작업할 수 있는 문제를 더 많이 잡습니다. 앱 code의 대부분은 외부 패키지에 의존하기 때문입니다. Snyk, Dependabot, 및 유사한 도구는 일반적인 시작점입니다.
If you’re also dealing with APIs that have to satisfy store and platform requirements, the security checks in your app pipeline should line up with the __CAPGO_KEEP_0__ security standards used for app store compliance, not just generic __CAPGO_KEEP_0__ rules. API security standards used for app store compliance, not just generic code rules.
실행 시기
| 검출 항목 | 주요 이점 | SAST | 개발, Pull Request, 빌드 시 |
|---|---|---|---|
| 위험한 __CAPGO_KEEP_0__ 패턴 및 불안전한 데이터 흐름 | 배포 전 빠른 피드백 | Risky code patterns and insecure data flows | Type |
| DAST | 개발 중인 앱에 대한 공격을 방지 | 실행 중인 앱의 런타임 취약점, 노출된 동작, 미설정 | 앱을 공격자와 같이 보는 |
| IAST | 인스트루먼테이션을 통해 실행 중인 앱의 취약점 | Code-레벨 및 런타임 문제 | 실행 중인 앱에 대한 인식으로 더 정확한 결과 |
| SCA | 의존성 설치, 빌드 및 업데이트 이벤트 | 취약한 세 번째-party 패키지 및 전이적 의존성 | 공급-chain 위험을 빠르게 노출 |
시간을浪費하지 않고 layering 방법을 어떻게 해야하는지
많은 팀들이 초기에 과도하게 구축합니다. 그들은 모든 스캐너를 모든 단계에 연결하고, 중복 알림을 생성하고, 개발자들이 알림을 무시하는 이유를 알지 못합니다. 더 깨끗한 접근 방식은 단계별 보안을 사용하는 것입니다.
- 빠른 code feedback을 위해 SAST를 사용하십시오. pull request에서 실행하고 규칙을 패턴에 집중하세요. 사용하는 언어와 프레임워크가 사용하는 패턴입니다.
- 모든 의존성 변경에 SCA를 사용하십시오. scheduled 스캔을 기다리지 마십시오. 패키지 업데이트가 위험을 도입한 것을 배운다.
- 실제 환경에서 DAST를 사용하십시오. staging 또는 리뷰 앱에 인증을 사용하여 실제 흐름을 볼 수 있도록 하십시오.
- IAST를 선택적으로 사용하십시오. high-risk 서비스에서 추가 컨텍스트가 운영 오버헤드에 가치가 있는 경우에만 사용하십시오.
구매해야 하는 스캐너를 선택하는 것이 아닌 현재 우리가 무시하고 있는 약점의 클래스를 결정하는 것이 올바른 질문입니다.
이 프레임이 프로그램을 실용적이게 만듭니다. 각 기둥은 다른 것들이 잡지 못하는 것을 잡아내서 자리을 차지합니다.
모던 앱 아키텍처 스캔
팀이 정리된 모바일 릴리즈를 배포하고, 일반 스캔을 통과하고, 라이브로 가서 릴리즈를 배포합니다. 세 일 후에, 팀은 UI 버그를 고치기 위해 자바스크립트 번들을 업데이트합니다. 이 번들은 클라이언트 측 유효성 검사를 변경하고, 셸이 호출하지 않아야 하는 브리지 메소드를 노출하고, 앱 스토어 빌드와 같은 보안 검사를 거치지 않습니다. 원래 릴리즈는 스캔되었습니다. code 사용자는 현재 사용 중인 릴리즈는 스캔되지 않았습니다.
전통적인 프로그램의 약점
많은 스캔 프로그램은 두 가지 목표를 중심으로 작동합니다: 저장소 내의 소스 code와 실행 중인 서비스가 노출하는 엔드포인트. 일반적인 웹 앱에 대해 이것은 어느 정도 잘 작동합니다. 그러나 배포 후에 의미 있는 변경이 발생하는 아키텍처, 여러 아티팩트에 걸쳐 변경이 발생하는 아키텍처, 클라이언트 셸이 업데이트된 콘텐츠를 로드할 수 있는 아키텍처는 커버하지 않습니다.
CapacitorJS와 Electron은 이 약점을 빠르게 노출합니다. 설치 가능한 바이너리는 공격 표면의 일부입니다. 자바스크립트 번들, CSS, 구성 파일, 기능 플래그, 원격 콘텐츠, 프리로드 스크립트, 네이티브 브리지, 업데이트 채널 등은 사용자가 사용하는 앱의 보안 태세를 영향을 미칩니다.
Wiz는 broader 문제를 Wiz의 애플리케이션 취약점 스캔 분석: 라이브 업데이트용 앱에 대해, 많은 팀은 배포 후 변경 사항을 충분히 스캔하지 않습니다. 이것은 프로세스 결함, edge case가 아닙니다.
실용적인 오류는 '앱'을 하나의 단위로 다루는 것이다. 현대적인 배포 스택은 층이 쌓여 있으며, 각 층이 다른 방식으로 실패한다.
- Client bundle risk: 업데이트된 웹 자산이 불안전한 DOM 처리, 인증 흐름을 약화시키거나 API 목표를 변경하지 않고 새로운 바이너리 검토 없이
- Container risk: 서비스 이미지는 오래된 OS 패키지, 공개된 도구, 또는 애플리케이션 code이 깨끗해 보이더라도 나쁜 베이스 이미지를 포함할 수 있다.
- Runtime drift: 프로덕션은 스테이징과 환경 변수, 사이드카, 시크릿 인젝션, 입장 규칙, 및 기능 플래그를 통해 스테이징과 다를 수 있다.
- Shell risk: Electron 및 Capacitor wrapper는 표준 웹 스캔이 보지 못하는 권한 모델, IPC 또는 브리지를 추가하고, 로컬 스토리지에 대한 문제를 추가하고, 업데이트기능을 추가한다.
현대적인 배포 경로에 추가해야 할 것
컨테이너화된 서비스는 리포지토리 스캔만으로는 충분하지 않다. 빌드 중에 이미지를 스캔하고, 배포 전에 최종 아티팩트를 스캔하고, 클러스터에서 실행 중인 것과 승인된 것과 비교해야 한다. Trivy는 파일 시스템 패키지와 컨테이너 이미지를 같은 워크플로우에서 다루기 때문에 일반적인 시작점이다. 그러나 단독으로는 충분하지 않다. 이미지 결과가 런타임 컨텍스트를 제공하지 않으면 code 경로에 nobody가 접근할 수 없는 문제가 많은 고정 큐를 만든다.
실시간으로 업데이트되는 앱은 더 엄격한 모델이 필요하다. 각 배ंडल을 release 아티팩트로 다루고, 각 아티팩트에 대한 보안 게이트, 버전 기록, 롤백 경로를 제공해야 한다.
That usually means four controls:
- 웹层를 배포하기 전에 번들을 스캔하세요.
- 장치에 설치된 번들의 버전을 기록하세요.
- 업데이트를 서명하고 전달의 무결성을 검증하세요.
- 작은 그룹으로 배포하여 문제가 발생한 업데이트가 제한된 범위에서 유지되도록 하세요.
이것은 소유권도 변경합니다. 보안 검토는 더 이상 저장소 제출이나 데스크톱 패키징에만 중단되지 않습니다. 업데이트 채널, 서명 프로세스, 번들의 재고, 롤백 시킬 Switch의 소유권이 somebody에게 있지 않으면, 스캔 프로그램은 의도적으로 블라인드 스팟을 가지고 있습니다.
아키텍처도 스캐너 범위가 변경됩니다. 단일 서비스와 분산된 함대는 같은 검토 부담, 자격 모델, 경고 라우팅을 생성하지 않습니다. monolithic versus microservice architecture 일반적으로 팀은 monolithic versus microservice architecture를 통해 취약성 소유권이 훨씬 더 어려워지기 전에 스캐너 범위가 더 어려워지기 전에 발견합니다.
이전 배포 시점에 이 아티팩트가 받아들여질 수 있었는지 여부를 한 가지 좁은 질문에 대한 답변입니다. 그것은 번들의, 이미지, 구성, 또는 셸 변경이 그 이후로 푸시된 경우에만 그것이 말합니다. 그것이 그것의 자체 검사를 거치지 않는 한.
이것은 많은 지침이 생략하는 부분입니다. 현대적인 앱 취약성 스캐닝은 프로덕션에서 실행 중인 code를 따라야 하며, 원래 배포 시에 배포된 code를 포함해야 합니다.
CI/CD 취약성 PIPELINE을 구축하세요.
A 팀은 금요일에 깨끗한 모바일 릴리스를 배포하고, 화요일에 체크아웃 버그를 고치기 위해 라이브 웹 번들을 푸시합니다. 앱 스토어 빌드는 모든 보안 검사를 통과했습니다. 화요일에 배포된 번들은 같은 경로를 거치지 않았고, 현재 프로덕션은 code pipeline이 검토하지 않은 상태입니다. 그 틈새는 많은 스캐닝 프로그램이 실패하는 곳입니다.
pipeline은 앱이 배포되는 방식과 일치해야 합니다. 웹 앱의 경우 일반적으로 code, 의존성, 컨테이너, 배포된 환경이 필요합니다. Capacitor 및 Electron 앱의 경우, 배포 후 업데이트 경로도 필요합니다. 스캐너가 머지 또는 스토어 제출에서 멈추면, 릴리스 라이프 사이클의 가장 위험한 지점 중 하나를 놓치게 됩니다.
실제로 유지되는 패턴은 스테이징 스캐닝입니다. 저렴한 검사를 일찍 실행하고, 더 깊은 검사를 나중에 실행하고, 배포 후 스캔을 일정에 맞추어 실행합니다. 빠른 보안 피드백을 원하는 팀은 일반적으로 설명된 습관을 채택합니다. CI/CD 워크플로우가 앱 보안을 개선하는 방법: 짧은 피드백 루프, 명확한 게이트, 그리고 반복 가능한 정책.
pipeline 형태에서 시작하세요
작동하는 기준선은 다음과 같습니다:
- Pull request 단계: infrastructure-as-code 및 빌드 구성에서 SAST, SCA, 비밀 스캐닝, 정책 검사.
- 메인으로 병합: 전체 의존성 해결, 컨테이너 스캐닝, SBOM 생성, 서명된 아티팩트 생성.
- 준비 중인 단계: 실제 환경에서 인증된 DAST를 실행하고 노출된 관리자 경로, 약한 헤더 및 위험한 기본 설정을 확인합니다.
- 배포 후 단계: 외부 검증, 런타임 시각화 및 사용자에게 도달하기 전에 라이브 업데이트 번들을 스캔합니다.
마지막 단계는 너무 자주 생략됩니다. 라이브 업데이트 앱의 경우 푸시한 번들을 릴리스처럼 다루고 정적 애셋 업로드처럼 다루지 마십시오.
실제 GitHub Actions 예시
기본 워크플로는 정적 분석을 위해 SonarScanner, 의존성을 위해 Snyk, 컨테이너 이미지를 위해 Trivy를 combination합니다.
name: security-pipeline
on:
pull_request:
push:
branches: [main]
jobs:
sast-and-sca:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test, --ci
- name: Sonar scan
run: npx sonarqube-scanner
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
- name: Snyk dependency scan
run: npx snyk test
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
container-scan:
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t app:${{ github.sha }} .
- name: Trivy image scan
run: trivy image --exit-code 1 app:${{ github.sha }}이것은 시작하기에 충분하지만, 릴리스를 관리하기에는 충분하지 않습니다. 프로덕션 PIPELINE은 일반적으로 네 가지 추가 항목이 필요합니다. SARIF로 결과를 업로드하여 개발자가 이미 작업하는 곳에 결과를 표시합니다. 빌드 아티팩트와 함께 SBOM을 유지합니다. pull request 및 릴리스 후보에 대한 별도의 실패 규칙을 정의합니다. 라이브 업데이트 앱의 경우 번들의 버전을 포함하여 커밋, 아티팩트 해시, 의존성 스냅샷 및 릴리스 매니페스트를 묶습니다.
pipeline이 사용되거나 생략되는 데 결정적인 요인은 몇 가지 implementation detail입니다:
- 정책에 따라, 찾은 결과의 양에 따라: 중요한 심각도, 알려진 취약점 또는 접근 가능한 취약한 code와 같은 정의된 조건으로 빌드를 차단합니다.
- 스캔 속도를 유지하여 신뢰를 보존합니다: 캐시 의존성, 스캐너 데이터베이스 재사용 및 pull 요청 경로에서 오래된 작업을 분리하세요.
- 인증과 함께 DAST를 실행하세요: 비회원 크롤링은 일반적으로 돈, 권한, 또는 계정 변경을 처리하는 code에 도달하지 못합니다.
- 주의 사항 검사와 릴리스 차단을 분리하세요: 개발자들은 모든 경고가 배달을 중단시키면 시스템 전체를 무시합니다.
- 배포 전에 업데이트 패키지를 스캔하세요: Capacitor 또는 Electron 라이브 업데이트 시 변경된 웹 자산을 확인하고 스캔 결과를 패키지 기록에 첨부하고 롤백 메타데이터를 릴리스와 함께 유지하세요.
자신의 구현 작업과 pair하기 좋은 좋은 walk-through입니다:
어떤 것을 게이트하고 어떤 것을 보고해야 하는지
스트라이트한 규칙이 보이지만 일반적으로 보안 대신 팀이 작업을 피하는 것을 학습하게 만드는 넓은 차단 규칙은 좁고 방어할 수 있는 게이트 규칙이 되어야 합니다.
성숙한 pipeline에서 잘 작동하는 정책은 간단합니다:
빌드 게이트 규칙: __CAPGO_KEEP_0__
code
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
팀은 스택을 실행하는 데 사용하는 인증된 스캔을 조정하고 결과가 개발자에게 도달하기 전에 중복을 제거하여 개발자에게 도달합니다. 증명 기반의 검증 및 상관관계는 도움이 되지만 정책 조정을 대체하지 않습니다. 만약 스캐너가 결국 사용되지 않는 모듈의 죽은 code와 결국 사용되지 않는 결제 경로의 접근 가능한 문제를 구분할 수 없다면, 출력은 백로그에 도달하기 전에 추가적인 검토가 필요합니다.
실제로 작동하는 트라이어지 플로우는 다음과 같습니다.
- 적용할 수 없는 발견을 제거하십시오. 규칙이 대상하는 런타임, 패키지, 엔드포인트 클래스 또는 기능이 앱이 사용하지 않는 경우, 규칙을 비활성화하거나 범위를 설정하십시오.
- 중복을 하나의 개선 항목으로 통합하십시오. weakness 하나당 owner 하나, due date 하나, discussion thread 하나가 있어야 합니다.
- 위험성이 집중된 곳에서 인증된 스캔을 다시 실행하십시오. 관리자 패널, 역할에 따라 제한된 흐름, 내부 API, 계정 복구 경로는 스캐너가 로그인할 때까지 깨끗하게 보입니다.
- 사업적 맥락을 초기에 첨부하십시오. 공개된 청구 화면의 반사 XSS는 내부 지원 도구에서 동일한 버그와는 다른 문제입니다.
취약점의 취약성과 폭파 반경에 따라 우선순위를 정하십시오.
스캐너의 심각도는 작업 큐의 시작점입니다. 그것은 작업 큐를 대체하지 않습니다.
I는 4가지 사항을 먼저 살펴본다. 문제가 실행 중인 앱에서 접근할 수 있는가. 영향을 받은 경로가 사용자 또는 인터넷에 노출되어 있는가. 공격이 진행 중인지 또는 완전한 취약점 경로가 있는지. 팀이 패치, 구성 변경, 기능 플래그 또는 임시 제어를 통해 위험을 줄일 수 있는가.
그 방법은 빠르게 결정을 바꾼다. 노출된 인증 흐름에 중간 심각도의 버그가 더 높은 심각도의 발견을 뒤로 미는 관리자 접근과 WAF 규칙 뒤에 있는 작은 문제보다 우선순위를 높일 수 있다. 사용할 수 없는 code 경로를 가진 의존성 CVE는 직접적으로 결제 또는 세션 경계에 있는 작은 문제보다 아래로 떨어진다.
일일 정리에서 단순한 필터를 사용하라:
| 질문 | 예 | 아니오 |
|---|---|---|
| 생산 환경에서 취약한 경로가 접근할 수 있는가? | 급여 | 우선순위를 낮추기 |
| 취약한 경로가 비신뢰할 수 있는 사용자 또는 인터넷에 노출되어 있는가? | 전선으로 치료하라 | 노출된 문제 뒤에 있는 문제로 대기하라 |
| 활성 공격, 공개된 취약점, 또는 강력한 공격자 관심이 있는지 확인합니다. | 바로 고치기 | 위험 검토 계속하기 |
| 오늘날 패치, 구성 변경, 또는 kill switch를 통해 위험을 줄일 수 있나요? | 위험 감소 먼저 배포하기 | code 보안 개선과 테스트 커버리지 계획하기 |
실제 공격자 기회에 따라 정렬하세요, 아니라면 보고서 양에 따라 정렬하지 마세요.
__CAPGO_KEEP_0__ 배포 경로와 함께 보안 개선을 연결하세요.
배포 시스템이 강제할 수 있는 동작으로 우선순위를 종료하세요. 그렇지 않으면 팀은 슬랙에서 위험에 대해 동의하고 다음 주에 취약한 code를 배포합니다.
표준 웹 및 모바일 백엔드의 경우, 높은 신뢰도 결과를 트래킹된 고치기와 소유자, 마감일, 검증 기준과 함께 연결하세요. Capacitor 및 Electron 앱의 경우, 추가 단계가 필요합니다. 이슈가 라이브 업데이트層에 존재하는지 확인하고, 스토어 리뷰를 기다리지 않고 수정할 수 있는지 확인하세요. 배포 후 결정은 많은 프로그램이 실패하는 곳입니다. 이슈를 감지할 수 있지만, 이미 사용자 기기에 있는 code에 대한 빠른 루프를 닫을 수 없습니다.
핫픽스 릴리즈를 지원하는 팀이 있다면, 현재 다음과 같이 정의하세요: 핫픽스 릴리즈에 포함할 취약점은 무엇인가요? 누구가 승인할까요? 롤아웃은 어떻게 단계별로 진행할까요? 롤백 신호는 무엇인가요? 5단계 프로세스: 핫픽스 배포와 Capgo __CAPGO_KEEP_0__
운영 중인 빠른 수정에 Live 업데이트
결과를 얻는 것은 단지 문제를 발견하는 것일 뿐입니다. 다음 질문은 사용자에게 안전한 수정을 빠르게 적용할 수 있는지 여부입니다.
서버 측 애플리케이션의 경우 패치가 종종 서비스를 다시 배포하는 것을 의미합니다. CapacitorJS 및 Electron 앱의 경우, 많은 급박한 수정은 웹层에 존재합니다: 자바스크립트 논리, 렌더링 경로, 콘텐츠 규칙, 기능 플래그, 복사본, 또는 구성.
스토어 리뷰가 너무 느리면
배포 후의 간격은 Live 업데이트 가 편의사항에서 보안 모델의 일부가 될 때입니다. 사용자들이 이미 취약한 번들, 안전하지 않은 구성, 또는 깨진_SANITIZE_규칙을 가지고 있다면, 빠르게 대체할 수 있는 제어된 방법이 필요합니다.
이 문제의 클래스에 대해 팀은 일반적으로 하나의 워크플로우에서 네 가지 기능이 필요합니다.
- 대상 롤아웃 채널: 내부 사용자에게 패치를 먼저 적용하고, 작은 프로덕션 코호트에 다음으로, 더 광범위한 릴리즈.
- 번들 서명 및 버전 기록: 정확히 무엇이 변경되었는지 알 수 있고, 무제어 아티팩트가 배포되는 것을 방지합니다.
- 장치별 관찰성: 장치와 버전별로 사용률을 확인하고 실패를 조사합니다.
- 자동 롤백: 새로운 실패 모드를 만드는 경우 빠르게 롤백합니다.
이 공간에서 하나의 옵션은 Capgo의 실시간 업데이트 워크플로우Capacitor와 Electron 앱에 서명된 웹 번들 변경을 적용하지 않고 스토어 리뷰를 기다리지 않고 있습니다.
보안 pipe line에서 가장 적합한 메커니즘은 승인, 감사성, 롤백과 같은 일반적인 릴리스 경로와 같은 것으로 다루어야 합니다.
안전한 패치 방법
빠른 패치로 인한 위험도 존재합니다. 업데이트 경로가 방대하면 패치로 인한 새로운 위험을 만들 수 있습니다.
- 안전한 운영 패턴은 다음과 같습니다. 문제를 재현하고 범위를 정의합니다.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
__CAPGO_KEEP_0__
__CAPGO_KEEP_1__
__CAPGO_KEEP_0__
팀은 보안 스캔을 체크리스트 항목으로 시작합니다. 스캔기를 설치하고 CI에서 실행하고 보고서를 내보내는 것입니다. 이것은 시작점으로는 괜찮지만, 아키텍처가 분산되고 릴리스 주기가 빨라지면 그만큼 유지되지 않습니다.
보안 모델은 문화적이고 운영상의 것입니다. 개발자들은 pull request에서 정적 및 의존성 검사를 기대합니다. 플랫폼 팀은 인증된 스캔 대상과 컨테이너 커버리지를 유지합니다. 보안 팀은 정책을 조정하고 결과를 연결하고 중요한 결과를 비즈니스 컨텍스트와 함께 라우팅합니다. 릴리스 팀은 라이브 번들을 배포 후 변경을 첫 번째 클래스 아티팩트로 다루고, 비공식 패치를 다루지 않습니다.
이 변화를 통해 스캔이 실제 위험 감소로 변합니다. 활동을 측정하는 대신 pipeline이 중요한 것을 잡고, 올바른 소유주에게 도달하고, 노출이 인시던트 리스폰스로 변하기 전에 고쳐지도록 합니다.
성숙한 프로그램은 여전히 의견이 있습니다. 좁게 막습니다. 지속적으로 스캔합니다. 노이즈보다 취약점을 우선합니다. 그리고 릴리스 일은 보안 이야기의 끝이라고 가정하지 않습니다.
CapacitorJS 또는 Electron 앱을 배포하고, 배포 후 결함을 해결하는 실용적인 방법이 필요하다면 Capgo 팀에게 자바스크립트, CSS, 구성, 및 자산 수정을 위한 제어된 라이브 업데이트 경로를 제공합니다. signed bundles, rollout channels, rollback protection, 및 장치 수준 관찰성은 자연스럽게 현대적인 취약점 관리 워크플로우에 적합합니다.
