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.

Where security-related rules come from

The vast majority of security-related rules originate from established standards: CWE, SANS Top 25, and OWASP Top 10. To find rules that relate to any of these standards, you can search rules either by tag or by text. The standards that a rule relates to will be listed in the See section at the bottom of the rule description. 

CWE

CWE stands for Common Weakness Enumeration. According to the CWE FAQ

Common Weakness Enumeration (CWE™) is a formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

The CWE is a hierarchy of weakness descriptions. The lowest level in the hierarchy is a "Weakness Base", which describes a granular weakness. Above Weakness Bases, are Weakness Classes and Categories. In general, rules are linked to Weakness Bases or Classes. 

Tools which meet certain requirements can be certified as CWE Compatible. Those requirements are:

• You must be able to search for CWE-related rules using a CWE identifier. To do so in the SonarQube platform, simply drop the CWE identifier (e.g. CWE-595) in the search text input on the rules page and run the search.
• Rules must be accurately linked to their related CWE items. To see the CWE mapping for a SonarQube rule, consult the rule's See section at the bottom of the rule description.
• You must be able to identify the relevant CWE from an Issue. To do so in the SonarQube platform, consult the related rule.
• The product documentation must include a description of CWE and CWE Compatibility.
• The version of CWE supported must be listed. The SonarQube langauge plugins support version 2.8.

In addition to searching rules by CWE id's, you can also search by the "cwe" rule tag.

To see which CWE items are covered for a language, consult the links below.명확히 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 Image Removed
• Objective-C

SANS Top 25

The SANS Top 25 list is a collection of the 25-most dangerous errors listed in the CWE, as compiled by the SANS organization. The current SANS list is divided into three categories:  리스트는 CWE에 목록 중 가장 위험한 25개의 항목을 모은 것으로, SANS organization이 제정합니다. 현행 SANS 목록은 컴포넌트 간 안전하지 않은 인터랙션(Insecure Interaction Between Components, IIBC), 위헌한 리소스 관리(Risky Resource Management, and RRM) 및 오류 가능성이 있는 대응(Porous Defenses, PD)의 세 종류로 구분됩니다.

The tags used for SANS correspond to its categoriesSANS 관련 태그은 위의 세 종류로 구분되어 있습니다: sans-top25-insecure, sans-top25-risky, sans-top25-porous.

To find rules relating to SANS Top 25, you can perform a text search for the category, or the relevant CWE item, or perform a rule tag search25와 관련된 규칙들을 확인하려면, 해당 카테고리로 문자열 검색을 하거나, 관련 CWE 아이템으로 검색하거나, 규칙 태그를 사용해 검색합니다.

OWASP stands for OWASP는 Open Web Application Security Project. According to its site, it is:

Project를 의미합니다. OWASP 사이트에 따르면:

OWASP는 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.

The OWASP Top 10 is a list of broad categories of weaknesses, each of which can map to many individual rules.

 개의 전세계적인 비영리조직으로 소프트웨어 포안을 향상함을 그 목표로 하고 있습니다. 우리는 소프트웨어 보안을 시각화(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.

To find rules relating to OWASP Top 10, you can perform a text search for the category, or perform a rule tag search10과 관련된 규칙들을 확인하려면, 해당 카테고리로 문자열 검색을 하거나, 관련 CWE 아이템으로 검색하거나, 규칙 태그를 사용해 검색합니다.