SonarQube Quality Model은 세 가지 종류의 규칙을 제공합니다: 신뢰성 (버그/bug), 취약성 (보안/security) 및 유지보수성 (코드 냄새/code smell) 입니다. 그러다 다르게 구분하면 단지 두 가지 종류의 규칙으로도 나뉩니다: 보안 관련 규칙과 그 이외의 규칙입니다. 실제로 이 두 그룹의 규칙이 발견하는 잠재적인 오류에는 큰 차이가 없으나, 해당 규칙들이 어디에서 연유했는지와 해당 규칙들을 강제하는 표준의 입장의 관점에서 차이가 있습니다.

보안 관련 규칙들에서 기대할 수 있는 것

To be clear, the standard for most rules implemented in SonarQube language plugins is very strict: no false positives. For normal rules, you should be able to be confident that whatever is reported to you as an issue really is an issue.

But for security-related rules, the story is a little different. For instance, a lot of security guidelines talk about how "sensitive" data should be handled (e.g. not logged, not stored un-encrypted, &etc.). But since it's not really possible in a rule to tell which data is sensitive and which isn't, the choice becomes: maintain the no-false-positives standard and don't implement security-related rules, or implement security-related rules with a different standard.

That's why security-related rules cast a wider net than you may be used to seeing. The idea is that the rule will flag anything suspicious, and leave it to the human security auditor to cull the false positives and sent the real issues for remediation. Such rules are tagged with "security" and off by default.

명확히 SonarQube 언어 플러그인에 구현된 대부분의 규칙들의 표준은 매우 명호가합니다. False Positives를 없애는 것입니다. 일반적인 규칙들의 경우 SonarQube가 발견한 이슈는 대부분 실제 이슈라고 생각해도 좋습니다.

그러나 보안과 관련된 규칙들은 상황이 조금 다릅니다. 예를 들어, 보안과 관련된 많은 가이드라인들은 "민감한(sensitive)" 데이터를 어떻게 다루어야 하는지(예를 들면, 로깅되어서는 안된다 혹은 암호화되지 않은 상태로 저장되어서는 안된다 등)만을 규정합니다. 그러나 하나의 규칙으로 어떤 데이터가 민감하고 그렇지 않을지를 가려니는 것은 거의 불가능합니다. 이러한 상황에서 두 가지 접근을 통해 해결책을 찾을 수 있습니다: 1) false-positive가 없는 기준을 유지하면서 보안과 관련된 규칙들을 구현하지 않거나 2) 보안과 관련된 규칙들을 새로운 기준으로 구현하는 것입니다.

이와 같은 이유로 보안과 관련도니 규칙들은 여러분이 기대하는 것보다는 느슨한 범위에서 이슈들을 검출합니다. 의심이 될만한 모든 이슈들을 검출하고, 보안 전분가가 직접 이슈를 리뷰하면서 false positive를 걷어내고 실제 이슈들만을 남기도록 권장합니다. 이러한 규칙들은 "security"라는 태그로 관리되며, 기본적으로는 비활성화 되어 있습니다.

보안 관련 규칙의 출처

대부분의 보안 관련 규칙들은 CWE, SANS Top 25 및 OWASP Top 10과 같은 기 업계 표준에 근거하여 작성되었습니다. 이 표준들과 관계있는 규칙들을 확인하고자 하는 경우, 태그 혹은 문자열로 해당 규칙들을 검색할 수 있습니다. 해당 규칙과 관계 있는 표준들의 목록은 규칙 상세 기술 항목 하단의 See 섹션에 표시됩니다.

CWE

CWE는 Common Weakness Enumeration의 약자입니다. CWE FAQ에 따르면;

Common Weakness Enumeration (CWE™)는 공통적인 소프트웨어 취약점들의 공식 리스트 혹은 딕셔너리입니다. 이 취약점들은 소프트웨어 아키텍처, 설계, 코드 혹은 구현 단계에서 발생할 수 있으며 외부에서 착취가능한(exploitable) 보안 취약점으로 이어집니다. CWE는 소프트웨어 보안 취약성을 기술하기 위한 공통의 목적을 달성하고, 이러한 취약점을 노리는 소프트웨어 보안 도구들의 표준적인 측정을 가능토록 하며, 취약성 식별과 완화 및 예방 노력의 표준화 척도를 제공하기 위해 만들어졌습니다.

CWE는 취약점을 계층별로 기술합니다. 계층의 가장 닞은 레벨을 "Weakness Base"로 기술하며, 이는 가장 원초적인 단계의 취약점을 의미합니다. Weakness Bases 위로 Weakness Classes 및 Weakness Categories가 존재합니다. 일반적으로 코딩 규칙들은 Weakness Bases 혹은 Classes들과 연결됩니다.

CWE의 특정 조건을 만족하는 도구들은 "CWE 호환(CWE Compatible)"이라고 불립니다. 요구 조건은 아래와 같습니다:

• CWE 식별자(CWE ID)를 사용해 CWE 관련 규칙을 검색할 수 있어야 합니다. SonarQube 플랫폼의 경우, 코딩 규칙 페이지에서 검색창에 CWE 식별자(예: CWE-595)를 입력하고 검색을 실행하면 해당 규칙을 검색할 수 있습니다.
• 코딩 규칙들은 관련된 CWE 아이템에 정확하게 링크로 연결되어 있어야합니다. SonarQube 플랫폼의 경우, 코딩 규칙 설명 하단의 See 섹션에서 SonarQube의 규칙과 CWE 규칙의 매핑을 확인할 수 있습니다.
• 이슈에서 관련된 CWE를 명확하게 식별할 수 있어야 합니다. SonarQube 플램폼의 경우, 관련 규칙에서 CWE를 식별할 수 있습니다.
• 제품 문서는 CWE 및 CWE 호환성에 관한 내용을 기술해야 합니다.
• 지원하는 CWE의 버전을 표기해야 합니다. SonarQube 언어 플러그인은 2.8 버전을 지원합니다.

추가로 CWE ID를 통한 검색과 함께, "cwe" 태그로도 관련 규칙을 검색할 수 있습니다.

언어별로 지원하는 CWE 아이템을 확인하고자 할 경우, 아래의 링크를 참조합니다:

• C/C++
• Java
• Objective-C

SANS Top 25

SANS Top 25 리스트는 CWE에 목록 중 가장 위험한 25개의 항목을 모은 것으로, SANS organization이 제정합니다. 현행 SANS 목록은 컴포넌트 간 안전하지 않은 인터랙션(Insecure Interaction Between Components, IIBC), 위헌한 리소스 관리(Risky Resource Management, RRM) 및 오류 가능성이 있는 대응(Porous Defenses, PD)의 세 종류로 구분됩니다.

SANS 관련 태그은 위의 세 종류로 구분되어 있습니다: sans-top25-insecure, sans-top25-risky, sans-top25-porous.

SANS Top 25와 관련된 규칙들을 확인하려면, 해당 카테고리로 문자열 검색을 하거나, 관련 CWE 아이템으로 검색하거나, 규칙 태그를 사용해 검색합니다.

OWASP는 Open Web Application Security Project를 의미합니다. OWASP 사이트에 따르면:

OWASP는 501(c)(3) 개의 전세계적인 비영리조직으로 소프트웨어 포안을 향상함을 그 목표로 하고 있습니다. 우리는 소프트웨어 보안을 시각화(visible)하여, 전세계에 있는 개인 및 조직들(individuals and organizations)이 실질적인 소프트웨어 보안 위협에 대해 정보 기반의 결정을 할 수 있도록 돕습니다.

OWASP Top 10은 (소프트웨어) 취약점을 넒은 범위에 분류한 것으로, 하나의 분류는 여러 개의 개별적은 규칙들과 매핑됩니다.

OWASP 관련 태그는 취약점 기준에 따라 구분되어 있습니다: owasp-a1, owasp-a2, owasp-a3, owasp-a4, owasp-a5, owasp-a6, owasp-a7, owasp-a8, owasp-a9, owasp-a10.

OWASP Top 10과 관련된 규칙들을 확인하려면, 해당 카테고리로 문자열 검색을 하거나, 관련 CWE 아이템으로 검색하거나, 규칙 태그를 사용해 검색합니다.