제 3장 리버스 엔지니어링과 프로그램 이해하기 (1)

목표 : 리버스엔지니어링에 대한 이해를 높이자.

리버스엔지니어링에 대한 정의 (from 위키백과)

일호기

오늘도 마찬가지로 일빠의 영광.

리버스엔지니어링의 기본은 시스템을 만든 사람들이 만든 가정을 알아내고 그런 가정을 이해하는 것이 기본이다. 일반적으로 개발자가 소프트웨어를 설계하고 제작할 때에는 많은 가정을 하게 된다. 패킷의 길이와 문자열의 길이 등등이 바로 그럿 것 이다. 많은 프로그래머들이 이러한 가정들이 언제나 옳기를 기대하면서 프로그램을 제작한다. 결과적으로 이것들은 모두 소프트웨어의 '취약점'이 된다.

논리의 집으로 들어가기

프로그램이 외부로부터 입력을 받는 부분은 정해져있다. 이런 데이터의 진입점들은 프로그램이 구동되기 위해서는 꼭 필요한 부분이다. 또한 공격자에게 노출할 수 밖에 없는 부분이기도 하다. 그 예로 온라인서비스를 제공하는 많은 소프트웨어들은 TCP/IP 포트를 통해서 데이터를 입력받는다. 그런 이유로 공격자는 TCP/IP 포트를 통해 진입하려고 시도한다.

리버스 엔지니어링

"리버스엔지니어링은 기계와 기계의 행동만 보고 그 기계의 청사진을 만들어내는 과정이다." 리버스엔지니어링은 프로그램의 논리적 흐름에 영향을 줄 수 있다.

왜 리버스엔지니어링이 필요한가?

리버스엔지니어링으로 프로그램의 논리구조와 논리를 배울 수 있다.  하지만 사실 배우고자 하는  많은 경우 리버스엔지니어링은 좋지 못한 목적으로 사용된다.

 

리버스 엔지니어링은 불법인가?

리버스 엔지니어링에 대한 범용법률은 존재하지 않는다. 하지만 리버스엔지니어링은 상용소프트웨어의 복사방지 메커니즘을 제거하는데 결정적인 역할을 하기 때문에, 적법성에 대해 혼란이 있다. 소프트웨어의 복사방지나 디지털 권리 관리 방식을 없애기 위해 패치하는 것은 위법이다. 소프트웨어 판매자들이 리버스엔지니어링을 못하게 막는 이유는 소프트웨어에 있는 취약점들이 노출되는 것을 꺼려하기 때문이다. 하지만 실력이 된다면 프로그램의 바이너리 코드만 바라봐도 소스코드를 가지고 있는 것과 똑같이 할 수 있고 논리적 흐름이 변경되도록 패치하는 것도 어려운 일이 아니다.

미국의 어떤 주는 EULA를 보고 '동의'를 클릭하는 것에 대해서 법적 효력이 나타나도록 하기도 한다. EULA에는  대부분 리버스엔지니어링을 하지 못하도록 하는 문구가 적혀져 있으며, 이것을 어길시 법적 처벌을 받을 수도 있다.

국내에서는 어떻게 처리되고 있는지 궁금해서 구글의 도움을 받아 다음과 같은 페이지를 찾을 수 있었다. http://simples.co.kr/?document_srl=18866&mid=QnA&sort_index=readed_count&order_type=desc

 

리버스엔지니어링의 도구

디버거

디버거는 다른 소프트웨어 프로그램에 붙어 흐름을 제어하는 소프트웨어 프로그램이다.

디버거는 사용자모드디버거와, 커널모드디버거가 있다. 유명한 커널모드디버거로는 Compuware에서 출신한 SoftIce라는 프로그램이 있다.

 

결함주입도구

결함을 주입하기 위한 도구이다 '논리적 집으로 들어가기'단락에서 이야기 했듯이 모든 프로그램은 '진입점'이 존재한다. 결함주입도구는 이 진입점에 문제를 발생시키거나, 개발자가 의도하지 않았던 결과를 유도하는 데이터를 주입시킨다.

역어셈블러

역어셈블러는 기계어 코드를 어셈블리 언어로 바꿔주는 툴이다. 컴퓨터사에서 유명한 인물인 '폰 노이만'은 기계어코드를 직접 읽을 수 있었다. 아마 그라면 역어셈블러조차 필요하지 않았을 듯.

역컴파일러

역컴파일러는 '어셈블리 코드나 기계어 코드를 C와 같은 상위 레벨 언어로 바꿔주는 툴' 이다. 좋은 역어셈블러/역컴파일러 쌍을 사용하면 역컴파일러 결과를 컴파일하면 애초의 바이너리와 동일한 바이너리를 얻을 수 있다.

 

리버스 엔지니어링 접근 방법

리버스엔지니어링을 하는 공격자는 무작정 리버스엔지니어링에 들어가기 보다는 일반적으로 취약점을 찾기 쉬운 영역들을 먼저 검사하는 것이 바람직할 것이다. 그런 영역들에는 다음과 같은 것이 있다.

• 부적절한 경계검사
• 형식화된 문자열로 이루어진 사용자 입력 데이터를 전하거나 소모하는 함수
• 형식화된 문자열에서 경계검사를 하는 함수
• 루프 속에서 사용자 입력을 받는 루틴
• 하위 레벨 바이트 복사
• 사용자 입력 버퍼의 포인터 연산을 사용하는 루틴
• 동적인 입력을 포함하는 '신뢰하는'시스템 호출

 

이런 전술적 리스트들은 수 많은 바이너리 코드속에서 꼭 필요한 취약점을 찾는데 도움을 줄 수 있기 때문에 중요하다.

리버스엔지니어링의 접근 방법은 크게 3가지로 나눌 수 있다. 그것은 화이트박스분석 블랙박스분석 그레이박스 분석이다. 각각의 자세한 설명은 다음과 같다.

화이트박스분석

간단하게 이야기 하면 '소스코드리뷰'라고 할 수 있다. 얻거나 직접 작성한 소스코드, 또는 역컴파일하여 나온 결과물을 '읽음'으로서 분석하는 것을 이야기 한다. 화이트박스 검사의 약점은 실질적 위협이 없음에도 취약점으로 판단할 수 있다는 것이다. 그 예로 응용프로그램 하나에는 수많은 '하위레벨 바이트복사'같은 위에서 언급한 여러가지 취약점이 존재할 수 있는 영역들이 존재한다. 하지만 그중에서 실질적 위협이 될 수 있는 것은 일부에 지나지 않을 것이다. 수 많은 strcpy중에서 진짜 위협을 가려내기란 쉽지 않을 것이다.

 

블랙박스분석

블랙박스분석은 소스코드가 없이 하는 분석을 의미한다.

 

 정용은

아 놔 영형 왜 또 하다 말았음? ㅡ,.ㅡ;; 그레이박스 분석 나와야 할 차례 아님 후웈...

저번주에도 나온 비슷한 얘기 같은데 많은 '프로그래머들이 이러한 가정들이 언제나 옳기를 기대하면서 프로그램을 제작한다' 그리고 이것은 보안취약점이 된다는데 동의한다.  많은 벨리데이션이들어가면 퍼포먼스가 조금씩 더 떨어지지만 그래도 보안에 구멍이 생기는 것 보다는 훨씬 저렴한 비용이라는 생각이든다.

• 일호기

주중에 마저 할거임 

 윤석균

 링크된 사이트에서는 "배포를 전제로 하지 않은 ,  개인의 연구목적으로 , 또는 프로그램이 돌아가는 원리를 확인하기 위해서  프로그램을 복제하는것은 허용이 된다."라고 나와있는데 이 말이 맞다면 리버스 엔지니어링 자체는 우리나라에서 불법은 아닌듯 하다.

패킷의 길이나 문자열의 길이같은 것을 귀차니즘으로 인해 경계검사 하지 않고 그냥 지나가는 코드들이 있다는 것에 공감한다.

 

정용은

 리버스 엔지니어링 접근 방법

그레이박스 분석

그레이박스 분석은 화이트 박스 기술과 블랙박스 입력 검사를 혼합한 것이다.

디버거로 대상 프로그램을 실행시키면서 특정 입력을 프로그램에 주입하는 방법도 있다.  이런 방식으로, 디버거는 실패나 잘못된 행동을 검색한다.

-> 어플리케이션 띄우고 VS로 네이티브 디버깅하면 그레이박스 분석 ㅡ,.ㅡ;

 

화이트박스 분석 - 더 많은 버그를 식별할 수 있지만 실제 위협은 측정하기 어려움

블랙박스 분석 - 진짜 문제를 찾을 수 있음

그레이박스 분석 -  앞서 나온 두 방법을 섞어 강력한 힘을 발휘함

 

대부분의 보안 검사의 문제점은, 아무도 하지 않는다는데 있다. - 이부분은 석균이가 코멘트 남기기로했다. 내가 하고싶었는디

 

변환기의 방법

입력 추적하기

입력지점을 결정하려면 시간이 많이 들지만, 사용자 주입 데이터를 기반으로 결정을 내리는 모든 코드 위치를 기록할 수 있는 기회인 셈이다.

-> 사용자의 입력으로 코드영향범위를 파악한다는 이야기

 

버전간의 차이 훔쳐보기

이전버전과 새로운 버전의 바이너리를 비교해보면 차이점들이 취약점을 찾기 위한 중요한 힌트가 된다.

 

코드 영향 범위 이용하기

코드 영향 범위는 프로그램 수행을 지켜보면서 실행된 코드 경로가 무엇인지 결정하는 방법이다.

 

커널에 접근하기

드라이버가 여는 핸들에 대한 접근 제어가 조악하면 시스템을 공격에 노출시킬 수 있다.

만약 드라이버가 사용자 모드 주입 값에 대해 정상 검사를 하지 않는 다면, 커널 메모리를 망쳐놓을 수 있다.  정교한 공격으로, 커널의 전역 상태를 수정하면 접근 퍼미션을 바꿀 수 있다.

 

공유 버퍼에서 데이터 빼돌리기

버퍼는 잠재적 데이터 누출을 찾아보기에 좋은 장소이다.

공개와 개인 데이터를 동시에 저장하는 버퍼는 정보를 누출할만한 장소이다.

 

예제 : 이더넷 문제

이더넷 패킷은 최소 66바이트가 되어야한다. 작은 패킷들은 66바이트를 채우기위해 데이터를 패딩시킨다.

문제는 칩들이 패킷과 패킷 사이에 버퍼를 총소하지 않는데 있다. 따라서 마지막 패킷이 남긴 버퍼값을 작은 패킷에다가 패딩시키게된다.  따라서 공격 패킷일지도 모른느 패킷에다가 다른 사람의 패킷을 누출하는 셈이다.

 

ARP 패킷으로 공격자는 다른 사용자의 TCP ACK 번호를 알아낼 수 있다.  알아낸 값은 일반적인 TCP/IP 납치 공격에 사용한다.

접근 요구 조건의 실수 감사하기

공격자가 DLL을 교체하거나 프로그램의 설정을 바꿀 수 있다면 공격자는 권한을 상승시켜 시스템을 총괄할 수 있다.

 

내가 만든 API 사용하기

APISPY를 통해 어플리케이션에서 사용될 수 있는 취약점이 있는 함수 호출을 찾는다.

잠재적으로 취약한 API 호출을 후킹하는 것은 사용자 입력을 취하는 호출처럼 매우 유용하다.

입력측에서 온 데이터가 취약한 API호출에 도착하는지 알아내면, 공격 방법을 찾은셈이다.

 

 

MS Spy 한번도 안쓰다가 책에나오는 APISPY를 보고 한번 써보게 되었다.

Winamp에 접근했다. 윈도우메시지를 거의 다 후킹하는것 같고, 문자열("WinampSongChange")도 보인다.

아흐 하고보니까 APISPY함 돌려보고 싶네 ㅡ,.ㅡ;;

 

• 윤석균

입력 추적하기에서 입력 지점을 결정하려면 시간이 많이 걸린다는 이야기가 무슨 소리인지 잘 모르겠다.

커널에 접근하기에서 드라이버가 사용자 입력에 대해 정상 검사를 수행하여야 한다고 나와 있는데 이 내용을 보면서 이런 생각이 들었다.

일단 패킷 검사나 문자열 검사나 모두 사용자 입력 정상 검사에 포함된다. 그렇다면 사용자 입력 검사를 하게되면 취약점이 많이 줄어들 수 있다는 이야기인데, 입력의 경우의 수가 단순한 경우가 아니라면 보통 검사해야할 경우의 수가 많을 것이다. 그렇게 되면 자동적으로 코드의 길이가 늘어난다. 그러면 1장에서 공부했던 1000줄당 5버그라는 복잡도 문제가 겹치게 된다. 물론 이런 이야기는 극단적으로 이론적인 이야기이긴 하지만, 검사코드 자체에 취약점이 없다는 보장(아이러니 하게도)은 없는 것 같다.

마지막으로 APISPY를 사용해 본 것은 좋았던 것 같다. 나도 내가 만든 프로그램에 한 번 사용해 봐야 할 듯.

 

윤석균

 

용어 별 정리

 

• 리버스 엔지니어링 ( 리버싱 ) - 대상 소프트웨어의 복잡함을 알아내는 기술. 기계와 기계의 행동만을 보고 그 기계의 청사진을 만들어내는 과정
• 패치 - 새로운 코드를 원래 코드에 추가하는 기술
• 디버거 - 다른 소프트웨어 프로그램에 붙어 흐름을 제어하는 소프트웨어 프로그램
• 결함 주입 도구 - 잘못된 형식이나 부적절하게 만들어진 입력을 대상 소프트웨어 프로세스에 공급하여 실패하도록 하는 도구
• 화이트박스 분석 - 소스 코드를 이해하고 분석하는 일이다. 실질적 위협이 없는 취약점을 보고할 수 있다는 단점이 있다.
• 블랙박스 분석 - 여러 가지 입력을 주어 실행중인 소프트웨어를 검사하여 분석하는 방법. 바이너리 코드도 필요 없기 때문에 프로그램을 네트워크 건너 원격에서 검사할 수 있다.
• 그레이박스 분석 - 화이트박스 기술과 블랙박스 입력 검사를 혼합한 것이다. 간단한 예로 디버거로 대상 프로그램을 실행시키면서 특정 입력을 프로그램에 주입하는 방법도 있다. 이런 방식으로, 디버거는 실패나 잘못된 행동을 검색한다.
• 코드 영향 범위 - 프로그램 수행을 지켜보면서 실행된 코드 경로가 무엇인지 결정하는 방법

 

밑줄 별 정리

 

 p97

소프트웨어를 공격할 때, 시스템을 만든 사람들이 만든 가정을 알아내고 그런 가정을 이해하는 것이 기본이다.

• 가정안에 취약점이 있다.

 

Microsoft에서 일하는 친구가 코드에서 공격할만한 곳을 찾기 위해 "assume"이라는 단어를 찾은 공격자에 관련된 일화를 들려주었다. 순진한 개발자들이 자신이 가정한 것을 코드에 써도 괜찮다고 생각한 모양이다. 이런 것이 사회적 수준의 공격 유형이다. BUG, XXX, FIX, TODO를 찾아보는 것도 좋다.

• 생각없이 작성한 주석이 공격자에게 약점을 제공하는 일이 될 수도 있다.

 

P98

공격자의 대다수는 TCP/IP 포트부터 찾는다.

• TCP/IP 프로토콜이 공격하기 쉽다는 이야기인듯.

 

스프트웨어는 범용 컴퓨터가 무엇을 할 지 결정하는 명령들의 집합이다. 따라서 어떻게 생각하면, 소프트웨어 프로그램은 컴퓨터와 명령들로 이루어진 특정 기계를 생성하는 것이다.

• 소프트웨어의 또 다른 정의.

 

p101

예를 들어, 대상 소프트웨어가 사용하는 시스템 함수 종류에 대해 알 수 있다. 대상 프로그램이 접근하는 파일도 알 수 있다. 대상 소프트웨어가 사용하는 프로토콜과 대상 네트워크의 다른 부분과 어떻게 통신하는지도 알 수 있다.

•  시스템 함수, 프로토콜, 네트워크 통신 방법(응용프로그램 단계의 프로토콜), 사용하는 파일이 취약점이 될 수 있다는 뜻을 내포하고 있다.

 

리버스 엔지니어링에 대한 범용 법률은 존재하지 않는다.

•  뒤에 나오지만 법률을 만들기도 애매하다.

 

p103

이런 동의서는 법정에서는 성립할 수도있고 아닐 수도 있다.

• 사이트에 회원 가입을 할 때라던지 프로그램을 설치할 때 생각없이 [동의]하며 넘어갔었는데 은근슬쩍 그런 것이 걱정되기도 하였다. 하지만 성립 안 할 수도 있다는 말에 방긋.

 

p104

디버거는 사용자 모드와 커널 모드 디버거라는 두 종류가 있다. 사용자 모드 디버거는 OS 아래에서 정상적인 프로그램처럼 실행되고 정상 프로그램과 같은 법칙을 따른다. 따라서 사용자 모드 디버거는 사용자 레벨 프로세스만을 디버그할 수 있다. 커널 모드 디버거는 OS의 일부분으로 디바이스 드라이버와 심지어 OS 자체를 디버그할 수 있다.

•  사용자 모드 디버거와 커널 모드 디버거.

 

p105

기계어 코드는 하드웨어 구조에 따라 달라진다(PowerPC 칩과 Intel Pentium 칩에 따라 달라진다).

• 그렇군요.

 

• 부적절한(혹은 아예 없는) 경계 검사
• 형식화된 문자열로 이루어진 사용자 입력 데이터를 전하거나 소모하는 함수
• 형식화된 문자열(%20s와 같은)에서 경계 검사를 하는 함수
• 루프 속에서 사용자 입력을 받는 루틴
• 하위 레벨 바이트 복사
• 사용자 입력 버퍼의 포인터 연산을 사용하는 루틴
• 동적인 입력을 포함하는 "신뢰하는" 시스템 호출

• 만약 리버스 엔지니어링을 통해 위에 해당되는 코드를 만난다면 취약점일 수 있다는 의심을 해봐야한다. 취약점을 검출할 때 유용한 리스트인 것 같다.

 

p108

대부분의 보안 검사(화이트박스이든 블랙박스이든 간에)의 문제점은, 실은 아무도 하지 않는다는데 있다.

• 생각해 볼 문제다.

 

p109

프로토콜을 리버스 엔지니어링하는 대신 숫자를 배치한 무작위 입력을 주는 간단한 검사를 실행한다. 생성된 데이터는 TCP 포트에 넣는다. 가능한 많은 "합법적인 듯한" 입력을 생성하여 포트에 주게 된다. 입력은 분당 20회 정도의 속도로 몇 분간 주입된다.

• 그레이스 방식으로 Microsoft SQL 서버의 결함을 찾는 방법.

 

p112

이런 차이점(버전간의 차이점)들이 취약점을 찾기 위한 중요한 힌트이다.

• 개발자가 주로 어떤 유형의 버그를 만들어 내는지 알 수 있다. 또한 패치되지 않은 소프트웨어의 버그를 알 수 있으므로 패치되지 않은 소프트웨어를 공격할 수 있다.

 

p114

버퍼는 잠재적 데이터 누출을 찾아보기에 좋은 장소이다. 공개와 개인 데이터를 동시에 저장하는 버퍼는 정보를 누출할만한 장소이다.

• 버퍼를 이용한 공격

 

p115

그럼 문제는? 칩들은 패킷과 패킷 사이에 버퍼를 청소하지 않는다. 따라서 마지막 패킷이 남긴 버퍼값을 작은 패킷에다가 패딩시키게 된다. 따라서 공격 패킷일지도 모르는 패킷에다가 다른 사람의 패킷을 누출하는 셈이다.

• 이더넷 문제에 의한 정보 유출.

 

ARP 패킷으로 공격자는 다른 사용자의 TCP ACK 번호를 알아낼 수 있다. 알아낸 값은 일반적인 TCP/IP 납치 공격에 사용한다.

• TCP/IP 납치 방법.

 

생각하기

 

  p108쪽에 나와있는 본문중에 "대부분의 보안 검사의 문제점은, 실은 아무도 하지 않는다는데 있다."라는 내용이 있다. 이런 내용을 보며 소프트웨어 개발 과정의 QA에 대해 나름대로 정리해봤다.

 

  QA는 Quality Assurance의 약자이다. 소프트웨어 개발에서는 품질 보증 검사 정도로 생각하면 될 것 같다. 이 책에서는 QA가 대부분의 상업용 소프트웨어 개발 과정에서 소홀해 진다고 말하고 있다. 만약 이 말이 사실이라면 왜 이런 일이 벌어지는 것일까? 몇 가지 이유를 생각해봤다.

 

 QA는 굉장히 지루하고 단순하고 반복적인 일이다. QA는 하나의 기능을 테스트하기 위해 여러가지 상황 설정을 하며 실행해야 하기 때문에 굉장히 반복적인 일이다. 또한 생산적인 일이 아니고 소모적인 일이기 때문에 지루한 느낌이 든다. 그런 특성 때문에 아무도 이 일을 하고 싶지 않을 것이다. 또 이런 반복적이고 소모적인 작업을 하기 위해선 많은 노동력과 시간이 필요하다.

 

 비전문적인 작업인 것 같으면서도 그렇지 않다. 프로그래밍 지식을 가지고 있는 사람과 그렇지 않은 사람이 QA 테스트를 하면 확연하게 다를 것이다. 프로그래머들은 프로그래머의 입장에서 프로그램을 쳐다 보기 때문에 대충 문제가 생길만한 곳이라던지 또는 구현하기 힘든 부분을 알고 있다. 그런 것을 알고 QA 테스트를 하는 것과 모르고 하는 것과는 큰 차이가 있다고 생각한다. 그런 큰 차이는 QA가 비전문적인 일이 아니라는 것을 말해 준다. 하지만 어떤 프로그래머가 QA 테스트를 하고 싶어할까? 또한 내가 인사담당자라면 안그래도 부족한 프로그래머들을 QA로 보내는 바보같은 짓은 하지 않을거 같다.

 

 이런 문제를 해결하기 위한 방법은 오직 QA를 위한 전문 인력 양성과 QA 방법 개선인 것 같다. QA를 하나의 학문으로 인정하고 대학이나 회사에서 전문적으로 교육해야 한다. 회사에서도 QA팀에게 고된 노동의 보상과 좋은 대우를 해주어야 한다. 기술적으로 가능할 지는 잘 모르겠지만 QA 과정을 자동화시키는 것이 최고의 방법이라고 생각한다. QA 과정을 자동화 시키면 QA 과정의 대부분을 컴퓨터에게 맡기고 특수한 부분만 사람이 처리하면 되므로 노동력을 아낄 수 있다. 하지만 역시 자동화 시키는 기술력 자체가 또 다른 문제로 다가온다. 그런 QA 소프트웨어를 만드는 것은 개발 소프트웨어의 개성 차이로 소프트웨어를 개발할 때 마다 개발해주어야 하므로 또 다른 QA 문제가 부딪히고 더 많은 인력과 돈이 들어갈 수도 있다.

 

 정용은

QA는 Quality Assurance의 약자이다 ㅡ,.ㅡ;;;
UnitTest를 통해 어느정도의 QA는 자동화가 가능하다. 예를 들면 날짜를 계산하는 루틴에 버그가 있었고 이를 고쳤다면 앞으로 발생하지 않게된다.  하지만 나중에 날짜 계산하는 루틴을 리팩토링하거나 계산공식에 변화를 주게 되었을 때 이버그가 다시 재발할 소지가 있다.  이런경우 UnitTest에 문제가 되었던 날짜계산을 넣어두고 빌드할 때나, 패키징할 때 성공/실패 여부를 확인하면 어느정도 자동화된 QA가 된다.

 

하지만 그래도 여기까지는 화이트박스 분석이다.

 

아무리 강력한 QA자동화를 하더라도 QA자동화를 구현한 부분은 결국 우리가 확인해서 테스트 할 수 있는 영역이다. 블랙박스 분석이 결국 사람을 통해서 QA를 해야하는데.... 이거 인력의 질적향상을 어떻게 하면 좋을지는 좀 더 깊게 생각해볼 문제이다.

 

 윤석균

네이버 검색을 했는데 컴퓨터 용어에 question and answer이라고 나와있어서 헷갈렸다. 뭔가 프로그램 자체에 질의 응답을 하는 것도 의미상 크게 어긋나지 않는 것 같았다...... 어쨋건 무식해서 ㅈㅅ

유닛 테스트가 자동화라고 했지만 내가 말한 자동화와는 의미가 많이 다른 것 같다. 유닛 테스트는 프로그래머가 프로그램을 개발하는 방법론이라고 알고있다. QA는 개발된 기능의 테스트나 완성된 코드의 보안 취약점을 찾는 단계라고 본다. 그리고 유닛 테스트는 프로그래머가 기획하고 프로그래머가 확인해야하는 단계인 것으로 알고 있는데 이것이 어떻게 자동화인지 이해가 되지 않는다. 내가 말한 자동화라는 것은 해당 소프트웨어에 대하여 자동으로 보안 취약점과 기능의 버그를 검사해 주고 결과물로 보고서를 출력해 주는 소프트웨어를 말하는 것이다.

  정용은

유닛 테스트를 얘기에 관심을 쏟다보니 잘 못 이해했다.

자동으로 소프트웨어를 이용해서 보안 취약점을 찾는건 위에서 윤석균이 언급한대로 기술력과 예외 상황을 예상해서 진행해야하기 떄문에 힘들다고 생각한다.