취약점을 찾아냅니다. 공격보다 먼저.

SaaS 제품은 공개적으로 접근 가능한 엔드포인트만으로 이루어지지 않습니다. 서로 다른 역할, 초대, 내보내기, 백그라운드 작업, 관리 기능이 함께 비즈니스 로직을 구성합니다. 그렇기 때문에 테스트 전에 어떤 프로세스가 특히 높은 보호가 필요한지, 애플리케이션이 어떤 경계를 지켜야 하는지를 명확히 합니다. 이러한 관점은 전통적인 기술 검증을 보완합니다. 어떤 기능은 형식적으로는 올바르게 응답하면서도, 로그인한 사용자나 그 테넌트에게는 의도되지 않은 작업을 허용할 수 있습니다.

이를 바탕으로 조율된 테스트 범위가 만들어집니다. 블랙박스, 그레이박스, 화이트박스 방식의 비중은 목표와 제공 가능한 정보에 따라 정해집니다. 소스 코드나 아키텍처 문서가 제공되면 관찰 결과를 더 정확하게 판단할 수 있습니다. 검증은 승인된 애플리케이션에 초점을 맞추며, 합의된 계정과 데이터를 사용합니다. 도구가 발견한 결과는 평가 없이 곧바로 확인된 취약점으로 간주되지 않으며, 영향과 전제 조건은 귀사의 팀이 이해할 수 있도록 제시되어야 합니다.

SaaS와 PaaS에서는 책임 경계가 결정적으로 중요합니다. 귀사의 애플리케이션이나 설정에 대한 검증이 자동으로 플랫폼 운영사의 인프라를 공격해도 된다는 허가가 되는 것은 아닙니다. 목표, 허용된 방법, 필요한 승인은 함께 문서화합니다. API와 연동은 의도된 데이터 및 권한 범위를 기준으로 검증합니다. 특히 서로 다른 역할과 테넌트가 실제 애플리케이션 경로에서도 확실하게 분리되어 있는지에 주의를 기울입니다.

레거시 소프트웨어는 흔히 다른 접근 방식을 필요로 합니다. 문서가 불완전할 수 있고, 테스트 환경이 운영 환경을 부분적으로만 반영하며, 일부 구성 요소는 부하에 민감하게 반응하기도 합니다. 이러한 조건은 시작 전 계획 단계에서 반드시 고려해야 합니다. 저희는 테스트 시간대, 연락 가능한 담당자, 중단 기준을 함께 협의합니다. 검증을 책임 있게 수행할 수 없는 경우에는 그 한계를 결과에 명확히 표시합니다. 이를 통해 테스트가 어떤 결론을 뒷받침할 수 있는지, 그리고 어디에 추가 조사가 필요한지가 분명해집니다.

보고서는 의사 결정을 뒷받침하고 개발팀의 수정 작업을 돕기 위한 것입니다. 그렇기 때문에 확인된 발견 사항에는 영향을 받는 버전, 필요한 전제 조건, 합의된 증빙, 가능한 영향이 함께 기술됩니다. 경영진과 기술팀은 서로 다른 수준의 세부 정보를 필요로 합니다. 우선순위는 단순히 동일한 비중의 항목을 길게 나열하는 대신 애플리케이션의 맥락을 고려하여 정합니다. 증빙은 필요한 범위로 제한되며, 합의된 경로를 통해 권한이 있는 담당자와만 공유됩니다.

조치 방안은 귀사의 팀과 논의하며, 합의된 재검증에서 구체적인 변경 사항을 평가합니다. 다만 발견 사항이 해결되었다고 해서 전체 애플리케이션에 취약점이 전혀 없다는 의미는 아닙니다. 새로운 릴리스나 설정 변경은 초기 상황을 바꿀 수 있습니다. 원하시는 경우, 이를 바탕으로 주요 변경 사항에 대한 정기적인 검증 체계를 마련할 수 있습니다. 또한 적합하고 명확하게 정의된 목표에 대해서는 Result as a Service를 합의할 수 있습니다. 이 경우 보수는 사전에 정의되고 입증된 결과에 따라 달라집니다.