소나큐브(SonarQube)란?
정적 분석툴로써 코드의 버그, 구린코드(Code Smell), 보안에 취약한 코드 등을 점검해주는 툴이다.
버그는 잘못된 코드나 개발자의 의도대로 동작하지않을 코드
구린코드는 정상동작은하나 유지보수가 힘들거나 중복, 복잡한 코드, unittest에 포함되지않은 코드등을 표시해준다고 한다.
보안은 SQL Injection, hard-coded 비밀번호, 제대로 핸들링 되지 않은 에러등을 발견해준다고 한다.
SonarQube Server는 코드를 분석하고 그 결과를 웹페이지 형식으로 볼 수 있게 해준다.
SonarScanner는 분석할 데이터(소스)를 전송하는 클라이언트
사용방법
- 자바스크립트의 경우
- https://www.sonarqube.org/downloads/ 여기서 SonarQube를 다운받아준다.
- 파일의 압축을 풀어준다.
- sonarqube폴더\bin\windows-x86–64\StartSonar.bat 를 실행 해 준다.
- http://localhost:9000 로 접속하여 로그인한다. 기본값은 admin/admin
- 자바가 환경변수 PATH에 설정되어있어야 한다.
- SonarScanner의 sonar-scanner폴더\bin 를 PATH에 등록해준다
- ‘package.json’ & ‘package-lock.json’ 파일이 있는 폴더에 ‘sonar-scanner.properties’ 파일을 만들어 준다.
- 이 파일안에
# must be unique in a given SonarQube instance
sonar.projectKey=test (The project key name)
# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName= test (The project name-can be the same as project key name)
sonar.projectVersion=1.0 (project version number)
# Path is relative to the sonar-project.properties file. Replace “\” by “/” on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=. (source code folder path, "." means all folders & nested folders in the current path)
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8 (Source code encoding, if your encoding is other than UTF-8 Remove the "#" and change the value Depending on the correct encoding )
sonar.java.binaries=.(source code binaries folder path, "." means all folders & nested folders in the current path)
를 저장해준다
- http://localhost:9000 로 가 Create A new project를 선택한다.
- Project Key와 Display Name을 입력한다(sonar-scanner.properties에 입력한 값과 같아야 한다, 여기선 test)
- 토큰명을 입력 후 generate를 누른다.
- Set up을 클릭한다.
- 여기서 사용언어(Other)와 OS 환경을 클릭한다.
- 다음 단계는 SonarScanner 를 다운받는 링크이다. 받아서 풀어준 후 PATH에 등록해주자(이미 했으면 안해도 된다)
- 화면에 보여지는 command 를 복사한다.
- 복사한 값을 해당 프로젝트 폴더로 가서 CMD를 켜 입력해준다.
- “Execution success” 메세지가 보이면 http://localhost:9000 로 가 ProjectS로 이동해 결과를 확인한다.
- 자바의 경우
- https://www.sonarqube.org/downloads/ 여기서 SonarQube를 다운받아준다.
- 파일의 압축을 풀어준다.
- sonarqube폴더\bin\windows-x86–64\StartSonar.bat 를 실행 해 준다.
- http://localhost:9000 로 접속하여 로그인한다. 기본값은 admin/admin
- 자바가 환경변수 PATH에 설정되어있어야 한다.(빌드툴들도 PATH로 등록되어있어야 한다)
- SonarScanner의 sonar-scanner폴더\bin 를 PATH에 등록해준다
- ‘pom.xml’ 혹 ‘build.gradle’ 파일이 있는 폴더에 ‘sonar-scanner.properties’ 파일을 만들어 준다.
- 이 파일안에
# must be unique in a given SonarQube instance
sonar.projectKey=test (The project key name)
# this is the name and version displayed in the SonarQube UI. Was mandatory prior to SonarQube 6.1.
sonar.projectName= test (The project name-can be the same as project key name)
sonar.projectVersion=1.0 (project version number)
# Path is relative to the sonar-project.properties file. Replace “\” by “/” on Windows.
# This property is optional if sonar.modules is set.
sonar.sources=. (source code folder path, "." means all folders & nested folders in the current path)
# Encoding of the source code. Default is default system encoding
#sonar.sourceEncoding=UTF-8 (Source code encoding, if your encoding is other than UTF-8 Remove the "#" and change the value Depending on the correct encoding )
sonar.java.binaries=.(source code binaries folder path, "." means all folders & nested folders in the current path)
를 저장해준다
- http://localhost:9000 로 가 Create A new project를 선택한다.
- Project Key와 Display Name을 입력한다(sonar-scanner.properties에 입력한 값과 같아야 한다, 여기선 test)
- Set up을 클릭한다.
- 토큰명을 입력 후 generate를 누른다.
- 여기서 사용언어(자바)와 OS 환경을 클릭한다.
- Maven 이나 gradle을 선택 해 준다.
- 누른 후 나오는 소스(위쪽)를 pom이나 build에 넣어준다.(\를 모두 삭제해줘야 한다)
- 화면에 보여지는 command(아래) 를 복사한다.
- 복사한 값을 해당 프로젝트 폴더로 가서 CMD를 켜 입력해준다.
- “Execution success” 메세지가 보이면 http://localhost:9000 로 가 ProjectS로 이동해 결과를 확인한다.
결과
분석 지표
공식문서의 분석지표이다
SonarQube 분석지표
품질 모델
SonarQube에 적용되는 규칙은 신뢰성(버그), 취약성(보안) 및 유지보수 (코드 냄새) 라는 세 가지 유형으로 구분이 됩니다. 규칙의 구분방법은 다음과 같습니다.
• 명백하게 틀린 코드에 대한 규칙이거나 잘못된 코드에 관한 규칙입니까?
대답이 “예”이면 신뢰성(Reliability, Bug) 규칙입니다.
그렇지 않다면,
• 해커가 악용 할 수있는 코드에 대한 규칙이거나 CWE , SANS Top 25, OWASP Top 10를 근간으로 하는 규칙입니까?
그렇다면 취약성(Vulnerability, Security) 규칙입니다.
그렇지 않다면,
• 규칙이 버그도 아니고 취약성도 아닙니까?
그렇다면 유지보수성(Maintainability, Code Smell) 규칙입니다.
Coverage
테스트 범위 및 실행
이 페이지에는 테스트 범위 및 실행 보고서와 관련된 분석 매개 변수가 나열됩니다. 다른 매개 변수에 대해서는 분석 매개 변수를 참조하십시오 .
출처: <https://docs.sonarqube.org/latest/analysis/coverage/>
심각도(Serverity)
SonarQube에서는 프로젝트 분석을 위해서 규칙들의 집합인 Quality Profile을 사용하며, 적용된 규칙이 얼마나 심각하고 중요한지 아래와 같이 5가지 수준으로 정의하고 있습니다.
• BLOCKER
프로그램의 동작에 영향을 줄 가능성이 높은 버그로 코드를 즉시 수정해야합니다.
ex) 메모리 누출, 닫히지 않은 JDBC 연결 등
• CRITICAL
프로그램의 동작에 영향을 줄 가능성이 낮은 버그 또는 보안 결함으로 코드를 즉시 검토해야합니다.
ex) 비어있는 catch 블록, SQL Injection 등
• MAJOR
개발자 생산성에 영향을 크게 줄 수 있는 품질 결함으로 시간을 두고 검토 해야 합니다.
ex) 중괄호로 덮여있지 않은 코드, 중복 코드, 사용되지 않은 매개 변수 등
• MINOR
개발자의 생산성에 잠재적인 영향을 미칠 수 있는 품질 결함입니다.
ex) 너무 긴 코드, 3개 미만의 switch 문 등
• INFO
버그이거나 품질상의 결함이 아닙니다. 인지를 위한 알림입니다.
품질 모델 등급
• Reliability(Bug)
A : 0개 버그
B : 1개 이상의 Minor 버그
C : 1개 이상의 Major 버그
D : 1개 이상의 Critical 버그
E : 1개 이상의 Blocker 버그
• Maintainability(Code Smell)
A : 추가로 발생한 Technical Debt가 프로그램 전체 Debt의 5 % 이하
B : 6 ~ 10 %
C : 11 ~ 20 %
D : 21 ~ 50 %
E : 50 % 이상
• Vulnerability(Security)
A : 0개 취약점
B : 1개 이상의 Minor 취약점
C : 1개 이상의 Major 취약점
D : 1개 이상의 Critical 취약점
E : 1개 이상의 Blocker 취약점
결과의 경우 품질게이트를 설정함 으로써 통과하는 기준을 정할 수 있다.
생각보다 security나 code smell에 걸리는게 너무 많다..
일단 security 쪽은 고치기 좋은 것 같다.
따로 룰을 정하거나 하지않는다면 오탈자나 중복, null 체크등 기본적인 품질체크밖에 되지않을 것 같다.