Skip to content

Commit 9c65c4e

Browse files
qmauvntqmauvnt
authored
Merge branch 'MichaelCade:main' into main
2 parents 5a8c0f5 + 6552c3a commit 9c65c4e

13 files changed

Lines changed: 1424 additions & 136 deletions

File tree

‎2023/day77.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ These are small subset of challenges when it comes to running and managing appli
99
Enter a Service Mesh. A Service Mesh is an application network layer that handles service-to-service communication, by providing a layer for granular traffic control, AuthN, AuthZ, and observability.
1010

1111

12-
### What are the challenges a Service Mesh aims to solve?m
12+
### What are the challenges a Service Mesh aims to solve?
1313
1. Unreliable and changing networks that are complex, while having to adapt while your microservices scale
1414
2. Ensuring a near zero-trust like environment where, RBAC, AuthZ and AuthN are critical.
1515
3. Ensuring a data-loss prevention approach using encryption and traffic filtration techniques

‎2023/ko/days/day14.md‎

Lines changed: 279 additions & 0 deletions
Large diffs are not rendered by default.

‎2023/ko/days/day15.md‎

Lines changed: 233 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,233 @@
1+
# 컨테이너 이미지 스캐닝 고급
2+
3+
## SBOM
4+
5+
**SBOM**은 **S**oftware **B**ill **O**f **M**aterials의 약자입니다.
6+
7+
이것은 소프트웨어 애플리케이션 또는 시스템을 구성하는 모든 구성 요소의 목록입니다.
8+
여기에는 소프트웨어를 구축하는 데 사용되는 다양한 타사 라이브러리, 프레임워크 및 기타 오픈 소스 또는 독점 구성 요소에 대한 정보가 포함됩니다.
9+
또한 SBOM에는 이러한 구성 요소의 버전, 라이선스 정보, 알려진 취약점 또는 보안 문제에 대한 세부 정보도 포함될 수 있습니다.
10+
11+
SBOM의 목적은 이러한 구성 요소를 나열하여 소프트웨어 사용자에게 소프트웨어 제품에 포함된 구성 요소에 대한 가시성을 제공하고 보안 또는 법적 이유로 유해할 수 있는 구성 요소를 피할 수 있도록 하는 것입니다.
12+
13+
[올해](https://www.immuniweb.com/blog/5-biggest-supply-chain-attacks-in-2022-so-far.html) 와 [작년](https://cyolo.io/blog/top-5-supply-chain-attacks-of-2021/) 지난 몇 년간 대규모 공급망 공격이 발생한 후 SBOM의 사용이 더욱 보편화되었습니다.
14+
15+
16+
컨테이너 이미지의 컨텍스트에서, 컨테이너 이미지에 대한 SBOM에는 다음이 포함됩니다:
17+
18+
- 컨테이너에 설치된 리눅스 패키지 및 라이브러리
19+
- 컨테이너에서 실행 중인 애플리케이션을 위해 설치된 언어별 패키지(예: Python 패키지, Go 패키지 등)
20+
21+
컨테이너 이미지에서 SBOM을 추출하는 데 도움이 되는 도구가 있습니다.
22+
23+
그러한 도구 중 하나는 [syft](https://github.com/anchore/syft)입니다.
24+
25+
예를 들어, syft를 사용하여 `ubuntu:latest` 컨테이너 이미지에 대한 SBOM을 생성할 수 있습니다:
26+
27+
```console
28+
$ syft ubuntu
29+
✔ Parsed image
30+
✔ Cataloged packages [101 packages]
31+
NAME VERSION TYPE
32+
adduser 3.118ubuntu5 deb
33+
apt 2.4.8 deb
34+
base-files 12ubuntu4.2 deb
35+
base-passwd 3.5.52build1 deb
36+
bash 5.1-6ubuntu1 deb
37+
bsdutils 1:2.37.2-4ubuntu3 deb
38+
coreutils 8.32-4.1ubuntu1 deb
39+
dash 0.5.11+git20210903+057cd650a4ed-3build1 deb
40+
debconf 1.5.79ubuntu1 deb
41+
debianutils 5.5-1ubuntu2 deb
42+
diffutils 1:3.8-0ubuntu2 deb
43+
dpkg 1.21.1ubuntu2.1 deb
44+
e2fsprogs 1.46.5-2ubuntu1.1 deb
45+
findutils 4.8.0-1ubuntu3 deb
46+
gcc-12-base 12.1.0-2ubuntu1~22.04 deb
47+
gpgv 2.2.27-3ubuntu2.1 deb
48+
grep 3.7-1build1 deb
49+
gzip 1.10-4ubuntu4.1 deb
50+
hostname 3.23ubuntu2 deb
51+
init-system-helpers 1.62 deb
52+
libacl1 2.3.1-1 deb
53+
libapt-pkg6.0 2.4.8 deb
54+
libattr1 1:2.5.1-1build1 deb
55+
libaudit-common 1:3.0.7-1build1 deb
56+
libaudit1 1:3.0.7-1build1 deb
57+
libblkid1 2.37.2-4ubuntu3 deb
58+
libbz2-1.0 1.0.8-5build1 deb
59+
libc-bin 2.35-0ubuntu3.1 deb
60+
libc6 2.35-0ubuntu3.1 deb
61+
libcap-ng0 0.7.9-2.2build3 deb
62+
libcap2 1:2.44-1build3 deb
63+
libcom-err2 1.46.5-2ubuntu1.1 deb
64+
libcrypt1 1:4.4.27-1 deb
65+
libdb5.3 5.3.28+dfsg1-0.8ubuntu3 deb
66+
libdebconfclient0 0.261ubuntu1 deb
67+
libext2fs2 1.46.5-2ubuntu1.1 deb
68+
libffi8 3.4.2-4 deb
69+
libgcc-s1 12.1.0-2ubuntu1~22.04 deb
70+
libgcrypt20 1.9.4-3ubuntu3 deb
71+
libgmp10 2:6.2.1+dfsg-3ubuntu1 deb
72+
libgnutls30 3.7.3-4ubuntu1.1 deb
73+
libgpg-error0 1.43-3 deb
74+
libgssapi-krb5-2 1.19.2-2 deb
75+
libhogweed6 3.7.3-1build2 deb
76+
libidn2-0 2.3.2-2build1 deb
77+
libk5crypto3 1.19.2-2 deb
78+
libkeyutils1 1.6.1-2ubuntu3 deb
79+
libkrb5-3 1.19.2-2 deb
80+
libkrb5support0 1.19.2-2 deb
81+
liblz4-1 1.9.3-2build2 deb
82+
liblzma5 5.2.5-2ubuntu1 deb
83+
libmount1 2.37.2-4ubuntu3 deb
84+
libncurses6 6.3-2 deb
85+
libncursesw6 6.3-2 deb
86+
libnettle8 3.7.3-1build2 deb
87+
libnsl2 1.3.0-2build2 deb
88+
libp11-kit0 0.24.0-6build1 deb
89+
libpam-modules 1.4.0-11ubuntu2 deb
90+
libpam-modules-bin 1.4.0-11ubuntu2 deb
91+
libpam-runtime 1.4.0-11ubuntu2 deb
92+
libpam0g 1.4.0-11ubuntu2 deb
93+
libpcre2-8-0 10.39-3ubuntu0.1 deb
94+
libpcre3 2:8.39-13ubuntu0.22.04.1 deb
95+
libprocps8 2:3.3.17-6ubuntu2 deb
96+
libseccomp2 2.5.3-2ubuntu2 deb
97+
libselinux1 3.3-1build2 deb
98+
libsemanage-common 3.3-1build2 deb
99+
libsemanage2 3.3-1build2 deb
100+
libsepol2 3.3-1build1 deb
101+
libsmartcols1 2.37.2-4ubuntu3 deb
102+
libss2 1.46.5-2ubuntu1.1 deb
103+
libssl3 3.0.2-0ubuntu1.7 deb
104+
libstdc++6 12.1.0-2ubuntu1~22.04 deb
105+
libsystemd0 249.11-0ubuntu3.6 deb
106+
libtasn1-6 4.18.0-4build1 deb
107+
libtinfo6 6.3-2 deb
108+
libtirpc-common 1.3.2-2ubuntu0.1 deb
109+
libtirpc3 1.3.2-2ubuntu0.1 deb
110+
libudev1 249.11-0ubuntu3.6 deb
111+
libunistring2 1.0-1 deb
112+
libuuid1 2.37.2-4ubuntu3 deb
113+
libxxhash0 0.8.1-1 deb
114+
libzstd1 1.4.8+dfsg-3build1 deb
115+
login 1:4.8.1-2ubuntu2 deb
116+
logsave 1.46.5-2ubuntu1.1 deb
117+
lsb-base 11.1.0ubuntu4 deb
118+
mawk 1.3.4.20200120-3 deb
119+
mount 2.37.2-4ubuntu3 deb
120+
ncurses-base 6.3-2 deb
121+
ncurses-bin 6.3-2 deb
122+
passwd 1:4.8.1-2ubuntu2 deb
123+
perl-base 5.34.0-3ubuntu1.1 deb
124+
procps 2:3.3.17-6ubuntu2 deb
125+
sed 4.8-1ubuntu2 deb
126+
sensible-utils 0.0.17 deb
127+
sysvinit-utils 3.01-1ubuntu1 deb
128+
tar 1.34+dfsg-1build3 deb
129+
ubuntu-keyring 2021.03.26 deb
130+
usrmerge 25ubuntu2 deb
131+
util-linux 2.37.2-4ubuntu3 deb
132+
zlib1g 1:1.2.11.dfsg-2ubuntu9.2 deb
133+
```
134+
135+
SBOM에는 컨테이너 이미지 내부에 설치된 패키지와 라이브러리가 포함되어 있을 뿐만 아니라,
136+
유형과 버전도 나열되어 있습니다.
137+
이제 이 목록을 취약점 데이터베이스와 상호 참조하여 컨테이너 내부에 취약점이 있는지 확인할 수 있습니다.
138+
139+
그렇다면 **취약점 데이터베이스(Vulnerability Database)**란 무엇인가요?
140+
141+
## 취약점 데이터베이스
142+
143+
취약점 데이터베이스는 소프트웨어, 하드웨어 및 기타 시스템의 알려진 취약점에 대한 정보 모음입니다.
144+
일반적으로 취약점의 유형, 취약점의 심각도, 취약점의 잠재적 영향과 같은 취약점의 특성에 대한 세부 정보가 포함됩니다.
145+
취약점 데이터베이스에는 취약점이 악용될 수 있는 방법과 해당 취약점에 대해 사용 가능한 패치 또는 수정 사항에 대한 정보도 포함될 수 있습니다.
146+
147+
일부 취약점 데이터베이스는 [vuldb.com](https://vuldb.com/), [NIST](https://nvd.nist.gov/vuln), [cvedetails.com](https://www.cvedetails.com/) 및 [Snyk 취약점 데이터베이스](https://security.snyk.io/) 등이 있습니다.
148+
149+
이들 기관은 사용자가 다운로드할 수 있는 API 또는 원시 데이터를 제공하며, SBOM의 패키지와 취약점 정보를 상호 참조할 수 있습니다.
150+
이렇게 하면 패키지에 주의해야 할 취약점이 있는지 확인할 수 있습니다.
151+
152+
일반적으로 이 취약점이 도입된 라이브러리 버전과 최신 버전에서 취약점이 수정되었는지 여부에 대한 정보도 찾을 수 있습니다.
153+
이 정보를 사용하여 취약점을 완화하기 위해 종속성을 업데이트/다운그레이드할지 여부를 결정할 수 있습니다.
154+
[14일차](./day14.md)에서 이미 설명했듯이, 종속성 업데이트에는 동작 또는 API 변경이 수반되는 경우가 있기 때문에 종속성을 업데이트하는 것이 항상 간단한 것은 아닙니다.
155+
156+
취약점에 대한 또 다른 중요한 정보는 취약점의 **CVSS 점수**입니다.
157+
158+
## CVSS
159+
160+
**CVSS**는 **C**ommon **V**ulnerability **S**coring **S**ystem의 약자입니다.
161+
162+
이 시스템은 취약점의 주요 특성을 파악하고 그 심각성을 반영하는 수치 점수를 생성하는 방법을 제공합니다.
163+
그런 다음 이 수치 점수를 정성적 표현(낮음, 중간, 높음, 심각 등)으로 변환하여 조직이 취약점 관리 프로세스를 적절히 평가하고 우선순위를 정할 수 있도록 도와줍니다.
164+
165+
기본적으로 하나의 취약점이 다른 취약점보다 더 심각할 수 있습니다.
166+
익스플로잇이 얼마나 쉬운지, 얼마나 큰 피해를 입힐 수 있는지에 따라 취약점의 순위를 객관적으로 매길 수 있는 시스템이 필요합니다.
167+
168+
이것이 바로 CVSS가 필요한 이유입니다.
169+
170+
CVSS v3는 CVSS 점수를 계산하는 8가지 기준을 정의합니다.
171+
이러한 기준은 다음과 같습니다:
172+
173+
### 공격 벡터 Attack Vector
174+
175+
취약점 악용이 가능한 컨텍스트를 반영합니다.
176+
177+
가능한 값 : **Network(N)**, **Adjacent(A)**, **Local(L)**, **Physical(P)**
178+
179+
### 공격 복잡성 Attack Complexity
180+
181+
취약점을 익스플로잇하기 위해 공격자가 통제할 수 없는 조건에 대해 설명합니다.
182+
183+
가능한 값 : **Low(L)**, **High(H)**
184+
185+
### 필요한 권한 Priviledges Required
186+
187+
공격자가 취약점을 성공적으로 익스플로잇하기 전에 보유해야 하는 권한 수준을 설명합니다.
188+
189+
가능한 값 : **None(N)**, **Low(L)**, **High(H)**
190+
191+
### 사용자 상호작용 User Interaction
192+
193+
공격자 이외의 사용자가 취약한 구성 요소의 성공적인 침해에 참여하기 위한 요구 사항입니다.
194+
195+
가능한 값 : **None(N)**, **Required(R)**
196+
197+
#### 범위 Scope
198+
199+
한 소프트웨어 구성 요소의 취약점이 리소스 또는 권한에 영향을 미칠 수 있는 능력입니다.
200+
201+
가능한 값 : **Unchanged(U)**, **Changed(C)**
202+
203+
### 기밀성 Confidentiality
204+
205+
성공적으로 익스플로잇된 취약점으로 인해 소프트웨어 구성 요소가 관리하는 정보 리소스의 기밀성에 미치는 영향입니다.
206+
207+
가능한 값 : **None(N)**, **Low(L)**, **High(H)**
208+
209+
### 무결성 Integrity
210+
211+
성공적으로 익스플로잇된 취약점이 무결성에 미치는 영향입니다.
212+
213+
가능한 값 : **None(N)**, **Low(L)**, **High(H)**
214+
215+
### 가용성 Availability
216+
217+
성공적으로 익스플로잇된 취약점으로 인해 영향을 받은 구성 요소의 가용성에 미치는 영향입니다.
218+
219+
가능한 값 : **None(N)**, **Low(L)**, **High(H)**
220+
221+
이 8가지 벡터의 조합에 따라 CVSS 점수가 결정됩니다.
222+
0에서 10 사이입니다.
223+
0이 가장 낮고 10이 가장 높습니다.(가장 위험)
224+
[이 곳](https://www.first.org/cvss/calculator/3.0)에서 각 취약점의 점수를 계산할 수 있는 CVSS 계산기를 찾을 수 있습니다.
225+
226+
## 리소스
227+
228+
<https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity>
229+
230+
<https://www.aquasec.com/cloud-native-academy/supply-chain-security/sbom/>
231+
232+
233+
[16일차](day16.md)에서는 "Fuzzing" 또는 Fuzz Test에 대해 살펴보겠습니다.

‎2023/ko/days/day16.md‎

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
# 퍼징 Fuzzing
2+
3+
'퍼즈 테스트'라고도 하는 퍼징은 컴퓨터 프로그램에 유효하지 않거나 예상치 못한 임의의 데이터를 입력으로 제공하는 소프트웨어 테스트 기법입니다.
4+
퍼징의 목표는 프로그램이 충돌하거나 의도하지 않은 동작을 나타내어 프로그램의 보안 취약점 및 기타 버그를 식별하는 것입니다.
5+
6+
퍼징은 수동으로 수행하거나 테스트 라이브러리/프레임워크를 사용하여 입력을 만들어서 수행할 수 있습니다.
7+
8+
퍼징을 더 잘 이해하기 위해 다음 코드를 예로 들어보겠습니다:
9+
10+
```go
11+
func DontPanic(s string) {
12+
if len(s) == 4 {
13+
if s[0] == 'f' {
14+
if s[1] == 'u' {
15+
if s[2] == 'z' {
16+
if s[3] == 'z' {
17+
panic("error: wrong input")
18+
}
19+
}
20+
}
21+
}
22+
}
23+
}
24+
```
25+
26+
이것은 '문자열'을 유일한 인수로 받아들이는 Go 함수입니다.
27+
28+
함수를 살펴보면, 제공된 입력이 '퍼즈'라는 단어인 경우 한 가지 조건에서만 함수가 'panic'(예: crash)을 일으키는 것처럼 보입니다.
29+
30+
물론 이 함수는 매우 간단하며 보기만 해도 그 동작을 알 수 있습니다.
31+
그러나 더 복잡한 시스템에서는 이러한 실패 지점이 명확하지 않을 수 있으며, 이를 테스트하거나 단위 테스트 케이스를 작성하는 사람이 놓칠 수 있습니다.
32+
33+
이때 퍼징이 유용합니다.
34+
35+
Go 퍼징 라이브러리(Go 1.18부터 표준 언어 라이브러리의 일부)는 테스트 케이스에 대한 많은 입력을 생성한 다음 커버리지와 결과에 따라 어떤 입력이 "흥미로운지"를 결정합니다.이 함수에 대한 퍼즈 테스트를 작성하면 다음과 같은 일이 발생합니다:
36+
37+
1. 퍼징 라이브러리가 작은 문자열부터 시작하여 크기가 커지는 무작위 문자열을 제공하기 시작합니다.
38+
2. 라이브러리가 길이 4의 문자열을 제공하면 테스트 범위의 변경을 감지하고(`if (len(s) == 4)`가 이제 `true`가 됨) 이 길이의 입력을 계속 생성합니다.
39+
3. 라이브러리가 `f`로 시작하는 길이 4의 문자열을 제공하면 테스트 커버리지의 또 다른 변경 사항(`if s[0] == "f"`는 이제 `true`)을 감지하고 `f`로 시작하는 입력을 계속 생성합니다.
40+
4. `u`와 이중 `z`에 대해서도 같은 일이 반복됩니다.
41+
5. `fuzz`를 입력으로 제공하면 함수가 패닉 상태에 빠지고 테스트가 실패합니다.
42+
6. __퍼즈__에 성공했습니다!
43+
44+
퍼징의 또 다른 좋은 방법은 코드 충돌을 일으킨 입력을 저장하고 매번 실행하여 퍼징을 통해 발견한 원래 오류가 다시는 코드에 도입되지 않도록 하는 것입니다.
45+
46+
이 역시 퍼징 프레임워크의 특징일 수 있습니다.
47+
48+
대부분의 퍼징 라이브러리에서는 테스트하려는 특정 값을 추가할 수 있습니다.
49+
이렇게 하면 우리가 이미 알고 있는 "흥미로운" 값을 라이브러리에 표시하여 생성된 값을 모델링할 수 있으므로 라이브러리에도 도움이 됩니다.
50+
51+
## 퍼징만으로는 충분하지 않은 경우
52+
53+
퍼징은 유용한 기술이지만 도움이 되지 않는 상황도 있습니다.
54+
55+
예를 들어, 코드에 실패하는 입력이 너무 구체적이어서 도움이 되는 단서가 없는 경우 퍼징 라이브러리가 이를 추측하지 못할 수 있습니다.
56+
57+
이전 단락의 예제 코드를 다음과 같이 변경해 보겠습니다.
58+
59+
```go
60+
func DontPanic(s input) {
61+
if (len(s) == 4) && s[0] == 'f' && s[1] == 'u' && s[2] == 'z' && s[3] == 'z' {
62+
panic("error")
63+
}
64+
}
65+
```
66+
67+
또는
68+
69+
```go
70+
func DontPanic(s input) {
71+
if s == "fuzz" {
72+
panic("error")
73+
}
74+
}
75+
```
76+
77+
이런 경우 퍼징은 아무런 단서 없이 정확한 문자열 `퍼즈`를 생성할 가능성이 적기 때문에 도움이 되지 않습니다.
78+
그리고 이전 사례에서 코드 커버리지 변경을 트리거했던 입력(크기 4의 문자열, `z`로 시작하는 크기 4의 문자열 등)은 이제 코드 커버리지를 트리거하지 않습니다. (이전 예제에서는 `if` 체크가 5개인데 비해 지금은 하나만 있기 때문입니다)
79+
80+
따라서 퍼징은 코드의 이상 징후와 코너 케이스를 감지하는 좋은 방법이지만 100% 올바른 코드를 위한 만병통치약은 아니라는 점을 이해하는 것이 중요합니다.
81+
82+
## 실제 예제
83+
84+
Go에서 퍼징을 직접 해보고 싶으시다면 [해당 주제에 대한 예제가 있는 내 리포지토리](https://github.com/asankov/go-fuzzing-101/tree/v1)를 확인하세요.
85+
86+
여기에는 이 글에서 사용한 예제와 실패를 트리거하는 퍼즈 테스트, 그리고 테스트를 직접 실행하는 방법에 대한 지침이 포함되어 있습니다.
87+
88+
## 리소스
89+
90+
- <https://en.wikipedia.org/wiki/Fuzzing>
91+
- [Fuzzing in Go by Valentin Deleplace, Devoxx Belgium 2022](https://www.youtube.com/watch?v=Zlf3s4EjnFU)
92+
- [Write applications faster and securely with Go by Cody Oss, Go Day 2022](https://www.youtube.com/watch?v=aw7lFSFGKZs)
93+
94+
[17일차](day17.md)에 뵙겠습니다.

0 commit comments

Comments
 (0)