[논문]무기체계 소프트웨어 신뢰성 시험 개선점 도출을 위한 소프트웨어 정적/동적 검증 분석 사례연구

박지현; 최병주

doi:10.3745/ktsde.2019.8.7.265

무기체계 소프트웨어 신뢰성 시험 개선점 도출을 위한 소프트웨어 정적/동적 검증 분석 사례연구
Analytical Study on Software Static/Dynamic Verification Methods for Deriving Enhancement of the Software Reliability Test of Weapon System 원문보기

정보처리학회논문지. KIPS transactions on software and data engineering. 소프트웨어 및 데이터 공학, v.8 no.7, 2019년, pp.265 - 274

박지현 (이화여자대학교 컴퓨터공학과) , 최병주 (이화여자대학교 컴퓨터공학과)

초록
AI-Helper

무기체계 소프트웨어 개발 시 수행하는 신뢰성 시험은 크게 정적 검증과 동적 검증으로 구분된다. 정적 검증에서는 소프트웨어 코드를 수행시키지 않고 코딩 규칙 점검, 취약점 점검, 소스 코드 메트릭 점검을 수행하고, 동적 검증에서는 요구 사항을 기반으로 실제 소프트웨어를 실행시켜 기능을 검증하고 코드 실행률을 측정한다. 이러한 정적/동적 검증의 목적은 소프트웨어에 존재하는 결함을 발견하기 위한 것이다. 그러나 현재의 무기체계 소프트웨어 신뢰성 시험만으로는 여전히 탐지할 수 없는 결함들이 존재한다. 본 논문에서는 소프트웨어에서 발생할 수 있는 결함에 대해 무기체계 신뢰성 시험의 정적 검증과 동적 검증으로 탐지를 할 수 있는지를 사례실험을 통하여 분석 한다. 그 결과로 현재의 정적 검증과 동적 코드 커버리지 측정에서 더 나아가 무기체계 신뢰성 시험, 특히 동적 시험의 개선방안으로 연결하고자 한다.

Abstract ▼ AI-Helper

The reliability test performed when developing the weapon system software is classified into static test and dynamic test. In static test, checking the coding rules, vulnerabilities and source code metric are performed without executing the software. In dynamic test, its functions are verified by executing the actual software based on requirements and the code coverage is measured. The purpose of this static/dynamic test is to find out defects that exist in the software. However, there still exist defects that can't be detected only by the current reliability test on the weapon system software. In this paper, whether defects that may occur in the software can be detected by static test and dynamic test of the current reliability test on the weapon system is analyzed through experiments. As a result, we provide guidance on improving the reliability test of weapon system software, especially the dynamic test.

주제어

표/그림 (11)

그림 Fig. 1. Example of MISRA Rule Avoidance
표 Table 1. Dynamic Software Defects
그림 Fig. 2. Defect Detection Ratio of Coding Rule
표 Table 2. Static Analysis Target
그림 Fig. 3. Defect Detection Ratio of CWE Check
표 Table 3. Target Applications
표 Table 4. Dynamic and Static Tools
그림 Fig. 5. Example of a Message Deadlock
표 Fig. 4. Defect Detection Ratio of Dynamic Defect Detection Tools
그림 Fig. 6. Example of an Atomicity Violation due to using Variable
그림 Fig. 7. Defect Detection Ratio of Runtime Error Static Analysis Tools

AI 본문요약
AI-Helper

* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.

문제 정의

본 논문의 주요 기여 점은 현재의 정적 및 동적 도구로는 탐지가 되지 않는 동적 무기체계 소프트웨어결함을 사례연구 및 실험를 통하여 분석한다. 그 결과로 현재의 정적 검증과 동적 코드 커버리지 측정에서 더 나아가 동적 결함 탐지하는 과정이 필요함을 보임으로써 무기체계 신뢰성 시험, 특히 동적 시험의 개선방안으로 연결하고자 한다.
그리고 일반적으로 결함 탐지에 사용하는 동적 결함 탐지 도구와 런타임 오류 정적 검증 도구에 대해서도 실험을 통해 결함 탐지 효과를 분석한다. 그 결과를 기반으로 무기체계 소프트웨어의 동적 시험에 대한 개선 방안을 이끌고자 한다.
소스코드 메트릭은 소프트웨어의 복잡도 감소, 유지보수 용이성 증대 등 소프트웨어의 품질 향상을 위한 소스코드의 품질 측정 지표로[3], 무기체계 소프트웨어 개발 및 관리 매뉴얼[3]에 따르면 함수를 기준으로 Cyclomatic Complexity, Number of Call Levels, Number of Function Parameters, Number of Calling Functions, Number of Called Functions, Number of Executable Code Lines를 측정한다. 그러나 이러한 소스코드 메트릭은 소프트웨어의 크기, 복잡도 등과 같은 구조적 특성이 결함 발생 확률에도 영향을 줄 수 있으므로[8] 그 값을 제한하여 결함 발생 확률을 줄이는 것을 목표로 한다. 따라서 [4]의 소프트웨어 결함을 직접적으로 탐지하지는 않으므로 분석 대상에서는 제외한다.
본 논문에서는 소프트웨어에서 발생할 수 있는 결함에 대하여 무기체계 소프트웨어의 정적 검증 방안 및 동적 결함 탐지 도구, 런타임 오류 정적 분석 도구가 얼마나 이들 결함을 탐지할 수 있는지 분석하였다. 그 결과 정적 검증을 통해서도 소프트웨어 결함의 일부를 탐지한다는 점을 보였다.
본 논문의 주요 기여 점은 현재의 정적 및 동적 도구로는 탐지가 되지 않는 동적 무기체계 소프트웨어결함을 사례연구 및 실험를 통하여 분석한다. 그 결과로 현재의 정적 검증과 동적 코드 커버리지 측정에서 더 나아가 동적 결함 탐지하는 과정이 필요함을 보임으로써 무기체계 신뢰성 시험, 특히 동적 시험의 개선방안으로 연결하고자 한다.

제안 방법

5MB이다. 그러나 SQLite로는 모든 결함을 적용할 수 없어 적용이 불가한 결함 유형에 대해서는 어플리케이션(Server_app, Client_app, DeviceControl, CharDevDriver, IHChangeLib)을 추가로 작성하였다. Table 3은 본 실험에 사용된 어플리케이션이다.
현재 무기체계 소프트웨어의 신뢰성 시험에서 사용하는 정적 검증 및 동적 검증 방안이 Table 1의 소프트웨어 결함 탐지에 얼마나 효과적인가를 분석한다. 그리고 일반적으로 결함 탐지에 사용하는 동적 결함 탐지 도구와 런타임 오류 정적 검증 도구에 대해서도 실험을 통해 결함 탐지 효과를 분석한다. 그 결과를 기반으로 무기체계 소프트웨어의 동적 시험에 대한 개선 방안을 이끌고자 한다.
런타임 오류 정적 분석 도구를 적용한 결과, Fig. 7과 같이 메모리 결함에 대해서는 Clang, Splint, Cppcheck가 각각 5개, 6개, 7개의 결함을 탐지하였고, 병행성 결함은 Cppcheck가 3개, Lint와 Relay가 각각 1개의 결함을 탐지하였다. 예외처리 결함의 경우에는 gcc에서 1개의 결함을 탐지하였다.
무기체계 소프트웨어 신뢰선 시험의 정적 검증 방안을 적용하였을 때, 소프트웨어 결함이 얼마나 사전에 탐지될 수 있는지를 분석하고자 한다.
셋째 동적 결함을 발생시키기 위하여 뮤테이션 기법을 이용해 결함을 인위적으로 주입하였다. 실험대상 어플리케이션에는 모든 동적 결함을 포함하고 있지 않기 때문이다.
소프트웨어 결함에 대한 정적 검증의 실험 결과를 코딩 규칙 검증과 취약점 점검 각각으로 구분하여 분석한다.
이러한 병행성 결함들은 반드시 해결이 되어야 한다. 이를 위해 병행성 결함 탐지 방안에 대한 최신의 연구들을 활용하여 무기체계 소프트웨어의 결함 탐지 도구로 구현하도록 하거나, 현재 소프트웨어 결함 탐지 도구의 성능을 개선하도록 하여야 한다.
신뢰성 시험에서는 자동화 도구를 이용하여 정적 시험과 동적 시험을 수행하여 소프트웨어 결함을 사전에 탐지하고 해결하도록 하고 있다. 정적 시험에서는 정적 분석 도구를 이용하여 코딩 규칙 검증, 취약점 점검 및 소스 코드 메트릭 점검을 수행하고, 동적 시험에서는 요구 사항을 기반으로 실제 하드웨어(Target)에 탑재하여 코드의 문장(statement), 분기(branch) 실행률, MC/DC (Modified Condition/Decision) 등의 실행률(coverage)을 점검한다.
본 장에서는 디버깅을 위한 결함 탐지 도구를 적용하였을 때의 Table 1의 소프트웨어 결함 탐지 여부를 실험을 통해 분석하고자 한다. 한편 추가적으로 동적 결함 탐지 방식은 아니나 관련 연구의 2.1에서 설명한 런타임 오류 정적 분석으로 소프트웨어 결함을 얼마나 탐지할 수 있는지도 본 실험을 통해 분석하고자 한다.

대상 데이터

첫째, 실험 대상 소프트웨어는 국내 무기체계 소프트웨어 개발 과정에서 사용하는 오픈 소스 소프트웨어 가운데 선택하였다. 무기체계 소프트웨어에서 사용하는 오픈 소스 6933개를 분석하였고, 그 중에서 1) Linux 기반에서 동작 가능한 C/C++ 어플리케이션이며 2) 메모리/병행성/예외처리 결함이 발생할 수 있는 함수를 사용하는 어플리케이션으로 SQLite[9]를 선정하였다. SQLite는 임베디드 시스템에 맞춰 경량화된 데이터베이스 관리 시스템이다.
NET Framework Design Guideline, 방위사업청 코딩 규칙 등이 있다. Table 1의 소프트웨어 결함은 C/C++ 어플리케이션에서 발생할 수 있는 결함을 타겟으로 하였으므로[4], 그 중 MISRA-C/C++[5,6]과 방위사업청 코딩 규칙[3]을 대상으로 한다.
둘째, 분석 대상 도구는 Table 4의 동적 결함 탐지 도구 4개와 런타임 오류 정적 분석 도구 6개를 대상으로 하였다. 적용 도구는 1) C/C++ 어플리케이션을 대상으로 하는 도구이며, 2) 실험을 위해 사용될 환경인 ARM 기반의 리눅스에 적용이 가능한 도구이다.
SQLite는 임베디드 시스템에 맞춰 경량화된 데이터베이스 관리 시스템이다. 실험에 사용한 버전은 3.24.0이고 소스 코드 파일의 크기는 8.5MB이다. 그러나 SQLite로는 모든 결함을 적용할 수 없어 적용이 불가한 결함 유형에 대해서는 어플리케이션(Server_app, Client_app, DeviceControl, CharDevDriver, IHChangeLib)을 추가로 작성하였다.
첫째, 실험 대상 소프트웨어는 국내 무기체계 소프트웨어 개발 과정에서 사용하는 오픈 소스 소프트웨어 가운데 선택하였다. 무기체계 소프트웨어에서 사용하는 오픈 소스 6933개를 분석하였고, 그 중에서 1) Linux 기반에서 동작 가능한 C/C++ 어플리케이션이며 2) 메모리/병행성/예외처리 결함이 발생할 수 있는 함수를 사용하는 어플리케이션으로 SQLite[9]를 선정하였다.
병행성 결함의 경우에는 7개의 결함이 탐지되었다. 탐지된 결함은 데드락 결함중 동기화 객체 데드락(C01)과 순서 위반 결함의 일부(C14～ C19)이다.

이론/모형

이것은 결함이 실행 과정에 따라 발생 여부가 달라지기도 하고 실행 환경에 밀접하게 관련되어 있는 경우가 많기 때문이다. 동적 시험에서는 LDRA tool, Cantata++, VectorCast, CodeSonar 등의 도구를 사용한다. 그러나 이 도구들은 코드 실행률 측정을 위한 도구이므로 결함 발견을 위한 도구와는 사용 목적이 다르다.
실험대상 어플리케이션에는 모든 동적 결함을 포함하고 있지 않기 때문이다. 메모리 결함의 경우에는 F.Wu 등 방안[14]과 H.Shahriar 등의 방안[15]을 적용하여 18개의 뮤턴트를 생성하였고, 병행성 결함의 경우에는 Markus Kusano와 Chao Wang이 제안한 CCmutator[16]와 Alper Sen이 제안한 뮤테이션 연산자[17]를 적용하여 97개의 뮤턴트, 예외처리 결함의 경우에는 Kim 등이 제안한 뮤테이션 연산자[18]를 적용하여 25개의 뮤턴트를 생성하였다. 각각의 결함 유형별 뮤턴트를 실험 대상 소프트웨어에 1개씩 적용한 결과 동일한 뮤턴트와 컴파일이 되지 않는 뮤턴트, 결함으로 동작하지 않는 뮤턴트를 제외하고 메모리 11개, 병행성 21개, 예외처리 16개의 결함을 발생시켰다.

성능/효과

동적 시험 평가 수행 중에 결함이 발생하여 동적 결함 탐지 도구를 이용하여 디버깅을 하게 되면 해당 부분에 대해 신뢰성 시험을 재실시하여야 하므로 개발 기간이 길어질 뿐만 아니라, 동적 결함 탐지 도구로도 탐지가 되지 않는 복잡한 결함의 경우에는 디버깅에도 매우 오랜 시간이 걸리게 된다. 3.2절의 정적 검증에서 활용할 수 있는 런타임 오류 정적 검증 도구의 경우에서도 소프트웨어 결함 탐지에는 한계가 있었다.
CWE-658은 메모리 결함 11개, 병행성 결함 7개, 예외처리 결함 1개를 탐지 가능하고, CWE-659의 경우 메모리 결함 11개, 병행성 결함 7개, 예외처리 결함 2개를 탐지 가능한 것으로 나타났다. 즉 취약점 점검을 통해서는 메모리 결함은 91.
Shahriar 등의 방안[15]을 적용하여 18개의 뮤턴트를 생성하였고, 병행성 결함의 경우에는 Markus Kusano와 Chao Wang이 제안한 CCmutator[16]와 Alper Sen이 제안한 뮤테이션 연산자[17]를 적용하여 97개의 뮤턴트, 예외처리 결함의 경우에는 Kim 등이 제안한 뮤테이션 연산자[18]를 적용하여 25개의 뮤턴트를 생성하였다. 각각의 결함 유형별 뮤턴트를 실험 대상 소프트웨어에 1개씩 적용한 결과 동일한 뮤턴트와 컴파일이 되지 않는 뮤턴트, 결함으로 동작하지 않는 뮤턴트를 제외하고 메모리 11개, 병행성 21개, 예외처리 16개의 결함을 발생시켰다.
본 논문에서는 소프트웨어에서 발생할 수 있는 결함에 대하여 무기체계 소프트웨어의 정적 검증 방안 및 동적 결함 탐지 도구, 런타임 오류 정적 분석 도구가 얼마나 이들 결함을 탐지할 수 있는지 분석하였다. 그 결과 정적 검증을 통해서도 소프트웨어 결함의 일부를 탐지한다는 점을 보였다. 또한 정적 분석을 통한 런타임 오류를 탐지하는 도구를 통해서도 일부 결함을 탐지할 수 있음을 보였다.
동적 결함 탐지 도구로 디버깅하여도 모든 소프트웨어 결함을 탐지하기는 못하였다. 따라서 정적 검증 이후 소프트웨어 코드 실행률 측정으로 이루어지는 현재의 소프트웨어 신뢰성 시험 검증 평가 방법에서 Table 1의 소프트웨어 결함이 없음을 확인하는 평가를 추가하는 개선점을 도출할 수 있었다.
메모리 결함 12개, 병행성 결함 21개, 예외처리 결함 16개에 대하여, MISRA C/C++은 메모리 결함 12개 모두, 그러나 병행성 결함 6개를 탐지하고, 예외처리 결함은 탐지하지 못하는 것으로 나타났다. 방위사업청 코딩 규칙을 적용할 경우에는 메모리 결함 7개, 병행성 결함 1개, 예외처리 결함 1개를 탐지하는 것으로 나타났다.
메모리 결함 12개, 병행성 결함 21개, 예외처리 결함 16개에 대하여, MISRA C/C++은 메모리 결함 12개 모두, 그러나 병행성 결함 6개를 탐지하고, 예외처리 결함은 탐지하지 못하는 것으로 나타났다. 방위사업청 코딩 규칙을 적용할 경우에는 메모리 결함 7개, 병행성 결함 1개, 예외처리 결함 1개를 탐지하는 것으로 나타났다. 즉 코딩 규칙 검증을 통해서는 메모리 결함은 100%, 병행성 결함은 28.
메모리 결함의 경우 각 도구들이 탐지한 결함이 달라 세 도구를 모두 결함 탐지에 적용할 경우 10개의 결함에 대해 탐지가 가능하고, 병행성 결함의 경우에는 Cppcheck과 Lint/Relay에서 탐지한 결함이 달라 4개의 결함에 대해 탐지가 가능하다. 즉 런타임 오류 정적 분석 도구를 통해서는 메모리 결함 83.33%, 병행성 결함 19.05%, 예외처리 결함 6.25%에 대해 탐지 가능하였다.
CWE-658은 메모리 결함 11개, 병행성 결함 7개, 예외처리 결함 1개를 탐지 가능하고, CWE-659의 경우 메모리 결함 11개, 병행성 결함 7개, 예외처리 결함 2개를 탐지 가능한 것으로 나타났다. 즉 취약점 점검을 통해서는 메모리 결함은 91.67%, 병행성 결함은 33.33%, 예외처리 결함은 12.5% 탐지 가능하다.
방위사업청 코딩 규칙을 적용할 경우에는 메모리 결함 7개, 병행성 결함 1개, 예외처리 결함 1개를 탐지하는 것으로 나타났다. 즉 코딩 규칙 검증을 통해서는 메모리 결함은 100%, 병행성 결함은 28.57%, 예외처리 결함은 6.25% 탐지 가능하였다.

후속연구

향후 현재의 동적 결함 탐지 도구로는 탐지가 어려운 결함을 탐지할 수 있는 도구를 개발하고 있으며, 그 효과를 분석하는 연구를 추진할 계획이다.

질의응답

핵심어	질문	논문에서 추출한 답변
	정적 검증을 수행하기 위한 자동화 도구 중 코딩 규칙 점검을 위해서 무엇이 사용되는가?	이 때 사용되는 자동화 도구는 코딩규칙 검증, 취약점 점검, 소스 코드 메트릭 측정과 같이 목적에 따라 달라질 수 있다. 코딩 규칙 점검을 위해서는 QAC, Code Inspector, Polyspace 등과 같은 도구가 사용되고, 취약점 점검에는 CodeSonar, Sparrow, Polyspace 등이 사용된다. 소스 코드 메트릭 측정에는 QA Framework(C/C++), Code Inspector, Polyspace 등이 사용된다.
	정적 검증이란?	정적 검증이란 소프트웨어를 실행하지 않은 상태에서 잠재적인 결함을 검출하는 것을 말한다[4]. 무기체계 소프트웨어 신뢰성 시험의 정적 검증에서 분석하는 내용은 주로 소프트웨어가 자동차 산업 소프트웨어 안전협회(MISRA) 코딩 규칙 혹은 방위사업청 무기체계 SW 코딩 규칙과 같은 소스 코드 작성 규칙에 맞춰 작성이 되었는지 여부, 소스 코드가 보안 취약 일반 유형(CWE) 목록에 정의된 취약점을 포함하고 있는지의 여부 소스 코드 메트릭 점검이다.
	무기체계 소프트웨어 신뢰성 시험의 정적 검증에서 분석하는 내용은?	정적 검증이란 소프트웨어를 실행하지 않은 상태에서 잠재적인 결함을 검출하는 것을 말한다[4]. 무기체계 소프트웨어 신뢰성 시험의 정적 검증에서 분석하는 내용은 주로 소프트웨어가 자동차 산업 소프트웨어 안전협회(MISRA) 코딩 규칙 혹은 방위사업청 무기체계 SW 코딩 규칙과 같은 소스 코드 작성 규칙에 맞춰 작성이 되었는지 여부, 소스 코드가 보안 취약 일반 유형(CWE) 목록에 정의된 취약점을 포함하고 있는지의 여부 소스 코드 메트릭 점검이다.

저자의 다른 논문 :

표제어: PCR

동의어: Packet Collision Rate

용어 설명 출처 목록 (6)

용어 설명: PCR은 세균 특이성이 있는 primer를 이용하여 적은 수의 세균이 있을지라도 쉽게 검출할 수 있는 유용한 방법이며, 이를 이용하여 구강 내 치면세균막이나 타액에서 직접 세균을 검출할 수 있게 되었다[8].

내보내기 구분	파일저장 인쇄 메일전송
구성항목	기본정보 상세정보 관리번호, 논문명, 저널/프로시딩명, 저자 , 발행년, 권, 호, 시작페이지, 끝페이지, 발행기관 관리번호, 논문명, 대등논문명, 저자 , 저널/프로시딩명, 발행기관, 발행년, 발행언어, 권, 호, 시작페이지, 끝페이지, ISBN, ISSN, 주제분야, 키워드, 초록(한글), 초록(영문), 저자(소속기관)
저장형식	Text(ASCII format) Excel format RefWorks Direct Export RIS format (for Reference Manager, ProCite, EndNote), Scholar's Aids, Mendeley
메일정보	받는사람 (필수) @ 보내는사람 (선택) @ 제목 내용 KISTI 검색결과 이메일 서비스
안내	총 건의 자료가 검색되었습니다. 다운받으실 자료의 인덱스를 입력하세요. (1-10,000) 검색결과의 순서대로 최대 10,000건 까지 다운로드가 가능합니다. 데이타가 많을 경우 속도가 느려질 수 있습니다.(최대 2~3분 소요) 다운로드 파일은 UTF-8 형태로 저장됩니다. 파일의 내용이 제대로 보이지 않을실 때는 웹브라우저 상단의 보기 -> 인코딩 -> 자동선택 여부를 확인하십시오. ~ Text(ASCII format) Excel format

연합인증