From 1f24478023d92c76372e92e478238a04cafd1658 Mon Sep 17 00:00:00 2001 From: Marco De Benedictis Date: Wed, 17 Jul 2024 16:28:37 +0200 Subject: [PATCH 1/7] style: tag-security logo max size (#1325) Signed-off-by: Marco De Benedictis --- website/themes/docsy/assets/scss/_logo.scss | 3 +++ website/themes/docsy/assets/scss/main.scss | 1 + 2 files changed, 4 insertions(+) create mode 100644 website/themes/docsy/assets/scss/_logo.scss diff --git a/website/themes/docsy/assets/scss/_logo.scss b/website/themes/docsy/assets/scss/_logo.scss new file mode 100644 index 000000000..67566e964 --- /dev/null +++ b/website/themes/docsy/assets/scss/_logo.scss @@ -0,0 +1,3 @@ +img[alt="Cloud Native Security Logo"] { + max-width: 500px; +} \ No newline at end of file diff --git a/website/themes/docsy/assets/scss/main.scss b/website/themes/docsy/assets/scss/main.scss index 8e28901e7..f85d894ba 100644 --- a/website/themes/docsy/assets/scss/main.scss +++ b/website/themes/docsy/assets/scss/main.scss @@ -27,6 +27,7 @@ @import "section-index"; @import "pageinfo"; @import "table"; +@import "logo"; @if $td-enable-google-fonts { @import url($web-font-path); From e9d4bddd794f25ed7bbe85ef67eb7cb6cb3d5254 Mon Sep 17 00:00:00 2001 From: Gaius Date: Wed, 31 Jul 2024 20:17:24 +0800 Subject: [PATCH 2/7] feat: add Dragonfly self-assessment (#1326) Signed-off-by: Gaius --- .../projects/dragonfly/images/arch.png | Bin 0 -> 22240 bytes .../projects/dragonfly/self-assessment.md | 367 ++++++++++++++++++ 2 files changed, 367 insertions(+) create mode 100644 community/assessments/projects/dragonfly/images/arch.png create mode 100644 community/assessments/projects/dragonfly/self-assessment.md diff --git a/community/assessments/projects/dragonfly/images/arch.png b/community/assessments/projects/dragonfly/images/arch.png new file mode 100644 index 0000000000000000000000000000000000000000..57f9617bec283a579f3ae49c008f435d551b3200 GIT binary patch literal 22240 zcmb@tWmFtN*DZ_$3m)9vW^gBHu;3Eh-F*m7aQ6U%ySux)3;_ZJcfugS!eAlTCC@8= z@BP;L=Fe20Q)kycyQFJ%bw{hIe8hZ9`W6lj4pUxE`V$-+A`}h|!5J0t)v`;WK?DZ} zKc}XoDf9C3LOOEx?c29kySTWxf`Y=z$_fby2_hn*g@r{ z5EBy3SbFfj1&@ML6U$jQmMxw&a+X-`j28yXr22ncFxYptxTP*70H%gZk>FWcMOsi>$V zBqXk`t~@h^Rd?Xz>s;sPh zLl2yvpKoev+S}VB?$~BzWF#mVzqz>?8X6iI89`GvB5GNCmrza8^Rv3T8pGW4=g*(W z+@gqNG}zu>F>M2I!wcVPSYbJbqXcA5}e`pfa)kbJT56dfUIQRcj9IwlL;>8_- zC(pkGau@M`_#jg8PL-21PGAe9OQ4QZY+CzO*P%vEA2^Sf1tvB5I}i$bY@LZiw!KE0 zXBhp)l&jo)-y6V_z3GK3C&b z1VGQE?(W`JpMbjm)cWl8{6W#VKd=I-PN=Rx#(Nt8Gb2_3028^$D>s(rW7GZdB1+bg zq1E{xC8^L#xyDppy5?i~qFpgo4MrWN)SetW!Tlaa-F0*Tm#x=|0`UK%_Vkly| zA(U)Zo05)^Df$Dy{z%4Gni@T!SX_Ascbd&JbJQ`e6(dD|5a+G2c-cTcq?@LKn)EkZXe4hPx``?T59i`OGoxA6i~#S2Gygj$&u;_vTQVB4_g< zc;}gLXJ?dsH_^9+2iy776YNss#vG>iRwLrnpE2bxX(O2jJ%BFElD!#!T1tgbehS~) zmtjva32iXv^CM!Ub6!c8n2vTp*p3y~imxv39PaT;l#nVft85 zj3gG@T5VBVcM1Z#5F7ZUp%(f~%*YgI8XEaf#%zJ0W<4%Aing(Jp#0#Oa;K6=f-iJ* zwMz|rRhvINb>W=`x=f8)^Yl4tavzL!w4a~h)+P)2pF6e?mPgih0rhreuzZOvO)<1s z*mxDBIHvNbs8Xc%Vr)=R(wGrFTu7&LRzlanlMA zt(tDo-H7p&5|jnWO2db;uY9N)peiXzs05|NKV27SUbIn@e}&M7*e#)$SLxjI2zD9t zglae)wqeCM#grXTD|e4BK0nua=$vo$EplsgVhr|F_P`yt7*ByuWaK{R9W;n!MrN4n zcR{{rtIz13C>DIs3|7gSv-#p$NAdU0i$x_`_&b-jYJ<-vxSPYS^_zBHIkPhKl6a&{ zy%GxH8Hjt9&qN#LHdEl%kCE^l)H)Y1P=Q{yBdcR_4EVD9QdjJ>2x0(G6Gyv%UghQi zjV@mOY@=@EN&U*1VQ90`B%Bc2$LZc5rD0!?%|l(&d5^~ zafXbdNm)Ur_33Q!w^uiP!0wv_h+fN!-2!Y*Ad>IF_GmthPMS>wGKX`o}fB z`;q+u>xkyXJOZ)0z0?_9&H39JYiC82k1ZaXgG3q%RP9|0U3S$|rQuwdaYsk&#|qLM zUW!clwm+=F@$$k&@2zpq;uX4*mZmclTJhe-1N9@7?AHD(fk)E|rR@2MB2ND?uOL~q z2x~mlC^D&zl8RHfSvVNzk7AUqaJ*95OC;9yL z`dC|^U1KXEf2PrG{~;h;zG)EeGmFhBv(cie_RLBx=hQF`_YdqVI7j@!0X`fu$yCov zn@00a^2@PyNn}R|dP~#~#=gBgL8T*pv+gKu{eX@B1Q6-4l`v~v^$pz8L|Q+h1CF69;WBIq(SbVbkD z*cfDLBikr)KMeB1-CdiEfj+q=5gn!Q8xQK(_~6UDG7%XW`n{?-)%wcA)0;y{`*U`K zk@OT>-~hSPUuz9i6;0M{RD@NT(;q5jr6wGmY_y~!I;0_-!Q5X4m2#nU;xjAm#uaJf zW^~QwK63FLY>{>-#XaFb;D6Cbiwqn1z>DL)x6XB-IYmM2g9stPw`WQre%_Nvh;l|C z?jF7D;Kh}xn}H#%;05_nwTn%|WHPjeiK*cq?(C(7l!PZtWB*GX)FAz^53MR=qVl|P1P4>YeH%Rr}c!RxcBsruoTaLzx%s(SbTJi93IXu>@sW+6x6FX>I)}V7e&;V7q%8DT zTt_7ti0wZp+OsX7h zU8`jt^p_$#Gzx!rgGd%kiOUbC6Qn~r%o+X5!phA@R-b9J+MW?yBen5fpxJK-afd*x5Nh{y|DmZZ%M8y_dg2BPhK)bhSAE#CeQ zKogRZdHyRv#ry1#lvjWu(66_wPK_Iph?83xcxVn$no|pFo9$u{)9xi$Rvs?F)FL6C zJ&pi@t zIJJpHF}o4Z1w)NMMq68fq*7P2_KB!fIN7wdxMBRoH*vP~_|+Pyj-0Na@F^PS6J|U5bI3+JczlEWv^t)3w31z8V{9RH4M6yzf54?c z&VOyuNpeI7D^La2d#WOISTWcA=v&sUeljkj#ud{U{{crZ3|AI7Gayyd0ngFi(`wl$ z^)JW=*;UgZAgVl`IqkUD)@n7rb&WNR;}lWG=UQSSp`ZbUc#$M>wdZo1wcT~fAQ(3g zClXUsx2`0Rusb+R*Xo`WdE)KttilOb{};yR&zG{+FY1i%y;C_Y7Xr}F?zdY2j-9N2 zkQ`K^vC8dzR;KirGJJavK~90vD{<4#A;8QNv$mdCjGz@&1OU8bHP9K# zy^2E|Zu)k(Xp?lQssVbTY*8M!$dCae-g4Hi-fRdi@Xh+m%eX^WAMbhQ>_5Udp{Bk@J{RlNJFAVuhw%IneNlM=qM~Ms7H~M zX&9Ab$k=@}0b11#r+uc1U{J5SKHSc=^Bc7nUAF)|2XOP#9#gQrCmf$k@-;*APGVVp z6caF%Q7P%DtFEd=EQ0kS6?2k!rwZTNKJ;l!ARF{gsvD98Xm zP(-m9M~u=J%+~K2T?O@NzAt=D5BzkAKty6VqTV1XM1i|O)bK$J!~W*y08T%<3xiY# z0~VQYgQ3a`B{jpqah2|K7=7(fnU;S4EQn}_z~ZNiYo0K!{XY#0!zli0h+6ckP*)m- zZ%g5@gfv4ue4wxTrHu#mLZR_wr)yWw;zh$nh-8)$_1f;pHCKM8wIy%FUj+<>QWtR$ z&se^3)M33d%`DrU1Jq{g_NjcepJIu-Cn6_umGBJvH$)sKhJ;$n^;P;Uq}+WCgTBgE zU-W79A~o0tenQ=PNMk`{O@vRe9Od3LS8p_|g+EMdPty5@8;RMgOBpQlT-$Gc4;VuC ztkDM4lCcE_ZRS)pZiJFx&sdutp*a5sALrv&G~2WX*NQlZ*s3*km_6I_7J_c8_&707 zK{`zBykA*^wAe3Xp<4HK1h`KbOzk=+U#z4a8t9o|AM^o^!!U&DD+da{@EBNM>~{czdVR7D_E6;!TC`_Q2E_j+JDAC zq8q+SWcp0dDS8rpI-)BUAhwnCcQktsJ5jrFJo{g&j8XdkEFIJH+r1u}E%W+xpLOyL z6S-)81Mst#Uni0``?rqr#(RO?P|es|!h!c~zlQt{WvYtEE*kp{;pBL$<<{Otpj44zHlNuDbZxLA}nE6@_AGj(Zj0-7VVtbs!Y~_dEF9&pd z18gtt`$6t=2&^yjF#kjXZ*$aMR75x8-L#jG#4G>Kga$aFEGi14f|YMFzxbJA104kj z%%z#!hugq0P#`@cb;qyt8);hk&;^dd(Rua>{#dBpgec#AM$ViB$QA`ZevX|0wV<4{mjo}TvP*qN2 z^$1y7F2cigd&w^K>v)%2QO(%j3@}o`Z?S~iA1~k}4}+}Ia4Jq|rLBL&Z2r-3ioas( zX;CjhuKnJnlXA;%KB6)Eym31x$1pZh!W20}Pft&14FLjt*SsC%^uDH#J>5>%bM1QE zA#{c5-+by>zYjy1F2+Y+3nrkJjzv5sHZ5Hl7x%liOF6`& zY;oU-qYV10weulvFGq>EPz<$DhB}{Z*V?7f7GQCXU`!;>r?jgvWT_V$)Y+K!Dd}Sncb+NT|;=OHipp zWzPmUPVz`6$=C!U6z@Dhdq8ydITReBblXzqY~NGeeJXiey2e!1C3!XL%8I*fjc%UK zVO7cb=YFfd#>Oa1iB()L&6~fSH|PH1(a@fp|Cl8~K!mctI`f6e25V zE*iBhz97!!K_%WSJM=y3-03n5n&uTF>Q6Vr!S(*lgdh{qb58jkPrk9P;s;sgZ&$Bw zfl)Xt9%OqOuQWLNqQi1$^Knr#z7MoF%8tnmB23qz!S4|TO(XRq*HI)UIHIpzaG92n z;3$cnFyUs=C_d!EAMJ7?sGY2!G&q;Mj77r_=$^2?#9sxz&K?Q4AKWo;e~ ztR|GyR6n2J=D&=93e`wb6N|oum(KpioOIXx?!2jb??IqUBsF3Q@!_8A?`BW_g=c}s zg#>f|4H^{B7I(!(LZ36O-W6iJ3V1Q>d@9Ksr(RvG&e*(m=)|^2XbAamTy|IaA0|v{ zBou80)Y|I~^cum|Zxzh^Tq2#I;9K{l&Gl2cXC!My!12U1fXUZ=NzF9%h!-+l3}xu5 zD}@?18){e)v*fjUN&i;@5;7UYQ$KZ)=;?EvI!o!9zfrp|# zn%^usDrDGrDTN^hx94s<9S++7VM>9wRSYq^^KGN5()6jSQj+&?UHs?>Zsy?bmB~pEdJbUJ013iL%q#{9sE~Kf61)thBrxBQF3KHU5 zn(PLb^#t3T@*zaPaBee2(4fmqsj3dISwQq~-^=7xCJ86a(k1yBx)ZTvYw2;NKBzar z3l$o^rfMVnF6ns)Tps)-O_6q#?_vuDUzjI#mPO9sI}t=i@;TDRO@X?w~>v_b{m;sV8O;plunOCm(g*SWp zL(!i(#jZL5po1G}{7Wg(tA<-5HyNoD1OufYC3#F1f z_xZLD%bKbP3Td)_Z_?Go_@P3-S=qYS#dCC&C7AOUWmAWhcJl!OLhqt_de+OU4U%hu zX;~#ZmoNe8T}X0bg@)H3AwXjpjeru!WS)V>IqG_49iu{I7YtQYijC+Tx0|l@Fe>Lv zI)en=7z@_zUF%uoLQJ$gPne=6rVS;8F}lglEH`xx4PpL@Xg?OrX$?O+zRoE#6ff$K zPsY|p!NY;rv`;})=PVwFFI3DmhDdduDJR=cypKK{W`o3I{I?%)*57@@fPEn+MyGxM zMlw=*EFxge>BBq8`wZ{`1+Nzk0kskJUuVQ7;V=)PntHRj)RT{W9mo);m`MQ!~dbcCgYZQNszSsHiXg*)*azyknk)pv&)egh)8db zU1p?Copq*zh$GH+z+^fm%2-razur32Nl^CRCBt}9D@g1`rP5g|j?if#d+_)8j>lww zN0BDZ>(s=op>9auf&sbaPDBHRZ+QPfzCCbX@vi)D86Jv`+@TH)BC50leEB76E|Rsh z(&?$=wR5?eym-ULMCD^4QEB)ql1bu6WPfE$5WHUdPZtb~$G>Hcy-w4@%9AeaS%+Im z0{xU5t42&k{_pfZzva<6*C@nqnB_~s!w$`3R$$x9#DJ~^Al#$+JO#DbvbOvpoOo_^ zDgQf40aQ_c2N|y*_qOe#u186-kT&~VfikLCdI5 z-#22Y-9c~fZmZ- zi)i5^@Zt70RT>|~)qnP0zs`Q;vZW6 zmZvIM)XHymt=EU;v?p3v?a(dwH4{7dr-ASuBf#wRJiMQJ6=)bRGQz7=4tUY1?fL>( zRsajcdsBP|-o^FT8KUIo#ATi4g8e=$59U>EaAH=QvymF%7w=ZkbvSB@5#5Z-hU?~{ zjp#6jp?<+=38#TsSz8-_oBh_q1IU-FaWNpE<;OEf&}aM`sC%zGkmfP=9!v#pBISlo zuw@%>2{Br|ESTE_gw}8{Pke@A@aG>jwf>M_^=j|vFjasEBe892&HUtp1#$rc)2dlk zRaJT&`vVp`I*zX5ee6kNer$+=3ZJjP7lzuWg=150Oo(vT9cAzC}hb^~mG}>TFJLXdogMMS;3v#n|`C17YHG$IR-*oZuoa zGQRgyK+Ypg%|xf_N3PGd`t9pavcj2jyMjykwV0_b^!zW$`nBEk)r()GtAP!r?JW-a zPf`YdbDQOjedJKSK&x?ZqrN08lmYUyBN=e%-*>{9h<$Kf>TibmWKhI6mn=ODUk%Yp zkj^moDgT6I>~Z~I#w;@~o!7MSE=16 zs4KY##B~CvOPU*+6g6606hF{_`kfzbcdnjO7`>Xdrx_-rOJ+n{2Qa})8++G;atezPm$@!#*;e}t#D^&0vhGthN*Z^;7{5SjDm-|pt|!*R502WTyT zZ0G9I%i1Mx4^a;GMH`br14s6|7iZ&1ZVbM2sNC$Y%LN;1;G!OF)tVz{`G3Z({zP zN^l`ZC(tD1PV$YZI_9qT?~hPC96UU9bcd-1fH@hMBLht47iekbk*~A$L&vg|=T`Pe z9J?0AevWMW6|=R~Y8@b6tU)_InD+(@?AFd(UT|0FevkTOPqs`MVb;g&j&P#@WHh)xqwDL*lKr~oL8Ly z$9C<4A#P00$Chfob7XB=?27Vt1d`g^IsvnSDgD?w&Ju~*=x1Yu&g&JAjr!j;v=(dZ z#r^h1ZuaXQfjDrq#qbDj8S6D7$RBds&AEeUnvjn&z=2phi9^dz2KOrybm(Fa+H4Mm zE%*vhH^H*LESLHo+>Q6XR;Wd`-wzI2Lo>hc z5BRvj8Dhawo>a1MF1D3Xhu2hJl+nN7KwND+?&|*eNKKN0`(ngY8&2Kr2mD-i;hyzP zIFJNk*l-=>vn!*uLT_r4~Rk+JMT}Q?)T0@D=seQdav$xEPe|ZN`->` z-k5xq(DgZL0EK}gv49`{Q*0qA9b#eDKIf<*clz|Bs&QCp{gsSuh==(YNubSY0;Y6qoZCLXCQVUumQAf3Z+qO zW}wlNmEY!8jJ{%;nj!qjW#kcOPz)^73bfATjo^s|KOh6KSMjmXkS63zFifI(5QBCd z_25c?w9CovZ4M7#HKuED*isOHcNp4~P1E366|9{w6~@%ZMAFLar3Qs-e)Ji8f#k$j zYCO6=6YPK&A;n~l{)wKAgz-9R@N@RJtL@2rvZdc=)bd7uO^>{1X5Z+u@kz zACu?w-iO}`fVg47=P9OL$pq?w55x3791AiPzGj|z6y;(%&26nVDO;sxdOO}N-x{+Y zppto3`yJoss33<;pl`c#^raI$m_hGrh)9So#2>%MuHU(K9jb4)Dto(9dSBug8F~Aw z*Ngbg*lqZ|z24ul(D98xc}O{9c~02$)b$ZN8QslJ)PzQFF_CT=Wrq&m)ms^-+W`9A zNsX3oAkBv&W8-hW^ZZ?J|Iqq@3RqY+y{>_#?JQ6uk{{p0elbkZx*&E|WdG#4=K%F8 zH?+u)(BZ>*#Y+Y4QtufRq?L_|opi_TU(gHs zavh0D-knnR#%A9vm7Cw^wNtHx;&qhR2))j;1`z2SI_A-Ip0`kv=6JhGNkX)IGicom zdc8QF?X{hFo?RV(Kk{uMRL1508T6`os==O9;4fubVdZB=C#8A<%@-S+(odno(IeS|`x03WqboST@(atlv`BeudJQSW$>(+{76KuiuqHYQrDhae7Heh% zh~9nw9mtzA^HZR4uM#%F4U>k;g5lkC8XT80#_!Yg?e=0)TPrAGk{mWReJt`1=Z9*` zPi$DDixg*QI1Ap(@OkF-k9jF4)xmf}5Vk@l(Hu>@Ls6+nr5JwDy<4;V#CyY#4B%D*3 z4CAhojs7C7+0cK77C>5*3vb>P0_M2{6XtF8^jsaS8nJnNb*?Aw+58F^2REP3 zK&L6p;?{coBcmEXWTsGlgo*s`pL$wxg}z;e|B~txnkeKyH>Qc11TW;%TJO+hrF@~R z>55p5O%K16(*N0aJA>#^lwsmSb2Q70&+{91dejqJ+w^6K59MwQ=s+s9sK{v^&Gf^& zh`Y~A^>XzI{$4&P32kjH45PMIvg}G=QEQR!-iloN*=zKtB>CG|b7)!AAAejLqlIJ! zWy!Q5i1IG-#;e2Op94Xi#z=EP5T9@uGW{K)R7TDcDfRWHHUybgLnxJ&vqVlM`FEwf z;}kZ3L;#B@3=_it2k|`uLnSk|g*H^<;NKlm(t6UDaazY~K4WO^NP-_Z(uW8;XB_-R>3Ad_QoleWQa?(j>Kg2tHD z`U>yE1NvZ5!@Dc2c$yR|G%12@MMHnqNUM`;-j2JGFu`sNd?~Q%mGlPw>@xB#oZy1lf?kw9dU!|NX}Y?6tXTC!sL;b_O^M-7tmZu;`s)UDX6|;G z5WH%Tz`#pid9Q}uaeavmub38N#$-Jy7_0W)I+H!K37L6@jXRSYKQ{TK4Op1UcYGIi zikuV&T>+%ej3w|DxndEfA)fFWR=!EgmDIg0+CqF27ElH{9K`FO{&~tQ1c-=sfvv~; z@MUn|CTeeCloLZ<454|VQ#)u%m9U{A`)}HJVdIVKSkxpkuF>37@t+WMgcPjcA&KxF zSGZ|sf~}$87e^@HJVK5`Or%tuv)}xc+ln%jqm^aPMe0uK$#WuXN|=9*gf%jYVjw zivQW$UfaEIqY7?Putewljzc=KL%qyJ$vR&9TzXJm`}qnyE7i*?+k)&@C$WzFP2-_c zcqi7OHT{O6EiU#zQfLVclT7*+5$xMO)#xO!Wa(A9rY4TQ-m4N8G|%ON&pVTE59OvH z^BQc%$TP@rZ$cDvVOUcrqzKli-{@d22pBuFo!Pjxg<9Ea-;J0gcAz96{2??oxg9}D z4d==S2bx_N2WCa=3C6wb4VTagdRaKXC*Ik}z>-EnB9IQA=$Q^C!oVFR=92wl@%TXD zbcm$h?gNBA__&LRW|*%t@z*%QBOSb#9OC{y-s6T?_wZqGAlk)EKhQY9#FB+ZgPiEy{n@TM`TZ~Yxv<_wL z6GCW<5C$*cF8vePvimoV?uT2TSMm)5+5SH9@C|V!o?-LhLg*H~GW(OU*XakO1K+%# z-x#sSQfde~nu=j0=2lu;e<>ccl7G6|czT+Fg#)0ToM&nQYZX1)25U1*v_E7?tj+DO zdvhbWCPoy0KJTi!fARFZWsq6_^D587l?qUN#xw*e_Pcu=JLOf-Wc@3ZcNSD*09lWLqUKL#Q))T9j(0d9~a*S#5c5RrsJL)*J<&gF>tbV|fya zb>{VJMX>MRBGxxG16jusyTIaA0mRG=B4a&1iq23xM?C_2i=3wCx5acy{Xc^P|6I6z zdv{EedV%c0KYkL%g)Pq|u-$pjklVvKG`JC$Xjl}CUJq>@x#8V!vAnb+oo-L_E!J`Ns zWX0a&^456=6+Ib|h$dR+91MDX0}NiiiCj7D+7O1N?GmPjm>c9xK}y7y|)=sNPcho`i4Bpbb|YOo|^n>=`8p`(TiHLu=65f z;t*2nk`axUrXc0`BmV~gXFB7Jh9Y=8a!I9!$L>OK>r|jyxAtZ^x5sHpwf|YVOr`FHDN~F3u>2q;mGv?*^LXmm=XEq(iaCP_8`=jM9T;OLulS{b*7i zra#r=TqZQ~OVVq_kWf@d9jbIJlet8;Qll!7sL$j#f%K59{V zcD;YWcy5epEvR>xCY7D_;CpNqAJ_ExUI7!Q8xpr>JBoQqgmnK^3XuU{$QSt8s6%(l zATr>{TmaE)bb+c6t`?>9fB(IADw<+A{k$ffuDEjC63w38uwaL0#BPT2_l)yj-15}_ z238qr`m9uf)S+hO|3S;M_y^~kVDxG}ZkaUcGdxGwcjm}w0ic#E-?BBdVeaa2+o|KI zWS<&PX!m&+5N&0&F#q$_Vgd7;y-Ap~vJC4Tjkz2Ws+s)KV?HW*79OsYdVHwtAv^S^ z0C8r)KE^s@d%c>Mr%FA7D|-IgBRe~O*uF^KpX|9AVBwHbOYB>RelLjSLwheuqQwh`GE$?^w8 zpMhR(_iJvzZPSFM^SI{55w9gmf>P%1#T(!MYSo>oPpp6Z=?edzS?#{xs$#Bq>ASCX z-KF}(_{X2Ai6cL*)GaJXzKDSbyi9%+N+nuLy}YjO{v!r{WHOlXy|tGjzPwlu89rvV zJEIt49@`W*NB5@8CbPUk)go8ShDZ2TpN-W7>-CsT$G#6?{1O`|lUIeP_4NtgFo20% z2RVNIHu)}4Pj$$Q#;2+^7W)RWHLq66u+}x0I7(toWtf5(`s0#UhQ0>puTa;|@@yMPAG43l*^DNHPcz#qRvnVoZhrk{W2M$5i^-Z z(#BV}=fxv8pbqkcJp|5OwfvEZ%?nH3a|5zG(&_%>%W8^O8*}LmYXqsfV~WD^PY;7E z$7}tSbA*@cKkhnYdDN1_8evAD1d4g@vL^GXr2fvmm9&ZBr?0j1cs|VIiKE%b`y;s$ zB~V*}V9&`IgZni>uR7yIgHCQSW1oi5{L-|t-W*{h0yTYwMtlw5)GYHZKeQaK>T@p* zb)cRb(1h%8X7S{e;Mhmt-Du^t0%k6@?Rtz&MNHrIh||wx{7=$e6`g_yl#Rlpo$hy0 zPum?};i?`7j?3Z?9e)vZ+UHpPxbc=%cJ)$F;O*N+H{1(M@LqD-0`?S8s5PH|GQr?J>oql#S!>~xw0bbn92-%^jamz~JNETcf{P+WDU;xm z!m8By8CRbEDH&G}}o_Nlg3PES(o8%BLC?KQh!0RdbH$*BDVDhc0>P zv1S8C5lU%K65xN;o3*YMq0$+Bl(LayH7_*(D{Ve(&ZC*zb3W0#A8w|H*bZxTJvZ#l zo7V39%YnDw&r+r-M%E6Bw9GlIrECXT1w9I2j{8BIUlWrX^V$0Ks&2%V=z_@DS`Ev> zPwhI4UcWM*xK=%lvhi9&65l(eD`JP{GNpf=CLt|pT;HzIq;X!GzWBpW_=$+aIK9Sy z+5!V6r#gU)b+`*Iy) z*=@T7MUrk+_Ymip4uJ3OS+mtjk5_N`La~uPhcq zq`=wCt3}_O3g7G?Aq&3x@iE2?$V;LY*IhjV-*O4*!0Fa6qDu)StmR$w!zxh4rIKO; zF+#Tt?dK_iUm^3UnXk+!f2*;4VeFsheRK2LQ^HkQ${M4YEpDIUNT$B)`kdzo*NYU} zqghjtRr{bP!U|wBXX}ZvhTC0V9@O&cT;sJQC^DWFOIDI=9wQ8cOhC`IK>raAJvpZs ztypCXCGCcj>(C29>V%0eP^OES%-^6@@L#}esrw<=MswO!h4fzE2mN#G55yZE{d-l{ z(S8E`Y8vj}P81`_V3Saa0KR-}mZF&wInc!A?UxVbU~#@Uqzs;OcC4&fLRrk8i%NT| z^BtGY*4F3Bd;23JlY@=om_IMGrT31FhP}D3ECW1$PgV?*Pzvf&lYJQLyn^slS-<1t zG5eN?A*P>|`Iq{1Q9i>+KN8X_`mg~>Zzc#xrqj}zUQ}ZQ;lzv}wgaNDqFP$C-YAgr z_kmu#(!Dm*4d+n^bbKjv#Nagq^39q}dl2wsPk~Ozc#{rP7AeF6D#`oUOg!XbxWVkJ zsN6HTI(h2h(;L8K)&QKep1*o^KuXV*&VY24u!Q=f}fk-5dusu>PG%;Xf9ilTyY|n^UfSJ0r+$B@WC#ge^W| zgmMs>Zq+@`S?E5Vl2AG`CxjT?N9^^$;;M+4qWdU~!p1Ec{(M+@&}sNhTMmBU$g2yz zsTNtn`qLIB9Rmmwy_q-58vo*7+zqNnvvzxlgglsKd&2=FX{W!hV~@LQc5a({|M`1k z$|=Z;|2F)5)1jrJz8;&YvMqXbqk)-&BR{Y2OZUQF)U+9yOT@m+!(Wxy^@W9{>Dqq$ z=E^p-b={X150txey*obqmJTry$Frd($Y4vt#_P918xb^%;=sX;H%cVv zzn9+neV1#n-S+<0mDFKp^!`4RN5r)OXW|9oq&0?tHtaoC!-W=0V%8a8bbeO(W~mwG z8I{#wbQ??(iNyl{-MG^b9j;}$9B>iNRtfQ;29fvG`TUTl9Oip|;&RAnndfdeZnMy*G|~ zgnjq~{Cxc3@&KoRhDwF`#YK<9nb(0)f4<>!nBYOOk=_ny&BI1UfNEv-itah;p9u?W+n?04hr^I@XV1n}i?kiF({UMKHm+ z*AK;(ozZsi?n%zm2WW1p&7CnY4Da$oZCUkv5Df{j9oNzOW4)(>x-R10M&<7a60ZPcbVxXM2b*8=~a1lm3}VK+nFdr`fJE8W%V z=fOU=j^wxC0jV2sxygWZsmCp_j*0+IdF8X?XE(Je)zDDcG zA-5dywtmVQCO6T$XKfas8ZK6XW?yc$w^V6DV>!iZhqar;HEn=eLNaO2WL62)MDHwy1xg$H@luEv^M z*nff|>_3sGYC?$$VdR<~gXi@Ppz&&RS@?G@2esny0}~qGCbJdMGQPA|!6vy(U56%K zTc|ew*8=$RN8Lt-un@PvMDpc_jK++VD=0}1$}&{+7QW*56kA0!1@jSJy*xEB!%q4^ zT^*f|dZ&mZ!rKRWj2#C6`1-x4U5MhS#LmuGeT-gwGFQM;`PYN>{@UXi_XxhyKlArh}Us_y?#6# zfiWY!!`qvbgxSXz$iGId|7g2dZ29*+nsk6&1pn<>npXp2!v1n-T;$nNS~xAG9{+#X z(OjQr9&jyLD`!%+!}?c++w&NQs4=irz(}fRZy76s>TvZn5*JAuN13yBDy2(hm2tij zhem_wc2SakcRLCByoqH!y`>06eSTF<8|N^wR@;We`aL+%2lQp zdJInrt0hJpFjs0uUO?pCXA^*9{ZAzcsV&g|yV=e!<$z7qGR|(v)OWs(;OGCAmq6Pw z^8amL0zD>9{tt;Q5b;LJSBrnm{$z{%UvB?*b4pt+abQZ?1o1-6;58iPy>=YD>HlPs zMg~V{k;RumSy1TNA~K&$&0qSI6R-dFj^L z)#F@Cdh}jn-bc`vAG5R)YH$Zg1d+xsOQ^0XwqDA)n}knIIvdeN8P}rc=;o_b_y%#K6O^mW(hZ7}>h^sTs6n5ZdwhbNLAc?@% z8ZY52q?;X;mvv{&T@*pLDIIiM%-$#I>n4KA3_*_2+>+a!tR_O*)d3ArBJROl> zX+PN|Eb}-!NN$!-*u34w3?dKFT^Wa=o&z7)-#!3*`Qqdg5ylai zuL6m$Ip(fwF#@{RjNVH>d7w zTarG*l+v;q?PHtg;=c#K2_Z`RuAJWB6X)VSxy{60%Ibq_ufZRGH})Ps9g>b9ItFsG81ipD<1V2*G{`r2=K#?fR=?9B%d!e}CBj`mpEtE!Fj zDCDK|tATaF+`P9Dut*lb636b>1UF)zpcMQaDZ0dL7lgcM+TB*n(eoF)l%E(w z49z%xR;P1?gSi5V*Kb8)2PNqjPbAV@i3}1<49QRDeSiB{^GFZAImOL`==C+d>Ljt3 zc>$b*)E_*npLG3$Kfp7&ytAV z!47uwb}Z+g(!{^K79o-N78ObK+DaRCkA{}9n<{~tavE$gAn({~(K{Btb#Y!0)5SS* zH2(!Iw|lJPDBEvbcSY@q6%1mdyO)f~;l!9b@M{8HzuWGXNVg{MgT@cRbWwZNCs)}@ z@rmA$u9e#g{)rk!tZajp0IvLvY;n;VSH44pm7*)laxlROjZANyhrA0Yt>Z?OepTw62zV6J?VXs8O;F?_Y0GWjZSn+<>L`*Q zQE!Fn%6)!SIG*`5a-(d^gLmLcs)mePE!L23Ady?wwcQvveGS`-!w_;8#wYuhM+XpT zsL>=9Zx9(e#!SIf65LrPjMQmP)0S*sYc>%CZ$e3i*C^0K7JXGhVsiQpD|M}v{sdun zN3Uf#OxzI4_kWHhI~(0kJhkj=h+|g#OwcQX{ns}9PRh<&wQV-x{hh;$sGUILW&)OM z3oY6a_HRYAQH^bq(^dni0-^~B>p>p`JXa&vVy3E2a_pBwiOIqJy;tk9K6>(tRd!YJ z!lQzqsX=lm_k5sR5Z4e-wXE9Y`2BYaiOneD<$G?U8JY2q6US(qG?&u@xwEc+?RWF0 z1EUyL=czRAjLLU@5MH#+C%6ul|I`&|e#AJo7GLs*^&9ac1E&c!B@zZjDV^wM%q5)- zg=H&?Xqh#`49^?Q_P7Ii^6veg#&RVNwhsnQVLMcUApI6bf?NCL=!W2qT#E`+O@lg% z_7pRuP^e3;W|`YJwv|b@w`!bNtg2@znRvJ*6+=jJxq4^T`p_$%Ku_@;^P; zz!;xS%Z^Uj$jG%ry47hdPcc|c< z@F_n&^y0`B46K&e?`Lw+w5Yo*9DuSxP|lA|npb+ZjS1nt%+N_Mi$_6hH(pzYPY7*=wl6T}wl zLNlt;WXEkw%4p@|b1+fN_KH$QdfATTH3G!l;4HQx=4-ybuvpiXNihkxiJEKbOsf;o zp{X~%jjGIc`F>T!nc0d&Hu^|k&O)|Dp^i1=+T?De4AX^E-~I|;YGksvKO#3UwMc(N zW0pOQyOFt*tee&`o#8wmSi8NnuWSF#$ym{~>G0NBjZqfJ@Z$s*@pvF~Hr!XH$m zooIB#f3pstvD90oglY#z$*AbdCUrj#7UvW;Cpw|-8d{@>^jLVHz!5oahSrIFnxFv1 zzQgExka}n(O!Kq5WLV8R>$uz3=QfkUcKMzFxq)oa-q#h&lkg)kDrvy@$bvUKnx&Ow~SAmmf<6fr?#YBmMvd0_x zW0@f^PXv5I>Up!?k>4iohDA=h<_+1WMX1G2e0c=Ca|G!OJmo) z==TM7GGYTOfRqY2Lo~aiJ1_x3Y|{sJ=||p2)8Ektl;IW40 z@57XWvtS^E$46_@hW2mg`vS6^;G66*vv26 zK`ON1@EXhZ2`!Ql>k6oQy_7M|uW+JYj(k~%Uqp6+`!38*(gG0Cp*}B&pO1iOP_1*Z z9b6FQ@?1t_N+7<|N8vYR5aF=0=G9}xDzebiI1t8q1Jx+R4??k7GuDmsS=`%dk+IV9*AE|P2*j@E;3Kw z^gn65R^9aT-L}s)l^~! z-e5D{wPM$JJ%sR7;L*iDki61VgYoHe7$CiNdMC!j)p#xLr2zI8pT)M+V7w3r=YfMx zJnF`4u^&|6VVm*6Z}na{l^TpPsK+Xm3LFl^dk_DmRX}D*d*KS)3Y@A=y0!p2^eoLT zmGcH><8|Y90qH*GBAfdSG+pA%X)kgkzrfJ=5;u3Nv-8R zUIi3%HSgaWV-Odn@;Lho48Bpd8Rw<*GI9wGoy4AA$g1c7pO(=XUKS>yw^)69@a&5C z8_@RQM7a;|`U-mW&yG?*`>m|h@5_bZkMTM|6!&pb?V&f){1Lxkt*kufPhS;2ErKte zV+fzDcvmPJy_jG1&=A#Otzw?^ai46DFGN$S$2S^WN-;MK?|lYuE83$$(7*HeF1kW^ zR{p7a1Rl>GgB~G*aqGOM3yl`wLQ&d(OIxzL z><4+{wS$9al`;(8^@x}X61Q%(E4noM0+ znhv$yrCT#PeB+{{^I#tKB%YOPx?&O@{WxCsB&TK?mxM$C{f*qx;rISi5<~bVbE|I5 zlf}?wj)ULRsKRy_j1? z5hS-RQrB|+y)irJfDRNf34-cy>m$DyuEt%P?+dF%p1bZ3%v`J%-p=Uv@G>6U zk064W>etA=1vxC0Onua~EKMlBR<((3DYb?EL!+L)O0#wJJ@1kq#W^ zx#}C%L7YYQtd4rjQGpn5wqeoiqBtxo#E?DkAsZ2|qx#g+B?_vwndC@3@S)Pun-D|s zr2=w*0+~~_F7dbZphBLZfFzV6!TBVb(Qj!`K>ophpG8u?-Swr!obca?v3Z1X8$#Fu zGUhiS1o8`nWClZfheUi%iT7QcA-R6zRJnO|er=$Lw8uK*(2CY`S8Fb4-s7doX&jSW z7^+~6mD~Bjy0XxQ-ZyFb0QJBV>4DJwT;)TDQUjn{_r5#kF8{qlZN1NSY>+de9bX6 zi~x8_gO5sS@VYA{1~b6OeapgZsv{|=>qm5iAgOt-94Gnz98e4>wxQCf!7k|;Hn0T78yBgixp%j6Vr1k=+mjW757UyT`?7lR_`?tnv-ZzP|`zs zJ_TAK-t!juNTUB?YNI&RVb;C$u3q=e1n4ZkT99mPRl8w=5gCDQHX+SA5rZzb>UmIb zOCG)Z-cUtA88igWdQ|2^W_d$)v75GPo??QrcFugNo_M2bZF)J2Jf%woY?>jOZ*elK ze3x;L!6j1&Pj)8*>1^y*n$Cre5Gh&sRVPJmo95f#MEH&_ZgiERBr(D|+_F-aw$j?i z7BL1_Djy3bfw8OU33+KZuoA+m%_VC6mV^sFRja?Y2X~}mrpvRy%D@f37qvSdN?YqT zDSb$`LIvn*I5;PS1VY=sipqfmO zStK`p=t8_RO6bnk%8Inp2-3C#czJH9!;^4PVMW)ZqTlgUf%04CL|#;rz*_9E zEyA&?B(dwB?~j8fMA(A%SuU%CNkD-FU^1uLDepLJ7awM}9mE;)${Jowidf6{G{aZM zFzW6FBqRx5k1vvr-}9Dur+UAZj{zV*2a#^Jw``Aeq& zlC!C3mBu3sG5!rty`O(KO34iqDli0D5&gTN{%&zKKJAHxzfAlKKa5wf_M#N5m!H&P z+p8krJ2+yI2me{|**_pRfNJSN9T*@6Tx+Q_=W8xI&~Hw!dq@kfpat+->!43&a3DCK zd0qv5TR5HQk#nr=qmJC%m@@F^^O#+PPnMC4a^Wz}ke zt-_4fr2`VjqHcKUsIptH0pOm3}FE|<2FInrieh%}rCF}HIBB#v9?pKKpoQ0caVV3I3Bx~d|-$pjU zsp&y-;Xp*3R5w`_pNN`_PS1aAj!0*B=&8Hwv*62rYetk5-a8t#LL4IUPt%KBF+Fc) zVCyysbL$V#7mTiFukI>@$7ZWIYVD6iU5!<7(EsfsN`SSyMeP*9qKOFmKQEB}|1PD@ Z9mH*#e**VQR1^Q240KGjt2CWo{~tBds*wNy literal 0 HcmV?d00001 diff --git a/community/assessments/projects/dragonfly/self-assessment.md b/community/assessments/projects/dragonfly/self-assessment.md new file mode 100644 index 000000000..e59a19939 --- /dev/null +++ b/community/assessments/projects/dragonfly/self-assessment.md @@ -0,0 +1,367 @@ +# Dragonfly Security Self-Assessment + +The Self-assessment is the initial document for Dragonfly to begin thinking +about the security of the project, determining gaps in its security, and preparing +any security documentation for their users. + +Authors: Wenbo Qi(@gaius-qi) + +Security reviewers: Tao Peng(@bergwolf), Wenbo Qi(@gaius-qi), Song Yan(@imeoer), Akash HR(akashhr), Xiongxiong Yuan(@yxxhero), Yiyang Huang(@hyy0322) + +## Table of contents + +- [Metadata](#metadata) + - [Security links](#security-links) +- [Overview](#overview) + - [Actors](#actors) + - [Actions](#actions) + - [Background](#background) + - [Goals](#goals) + - [Non-goals](#non-goals) +- [Self-assessment use](#self-assessment-use) +- [Security functions and features](#security-functions-and-features) +- [Project compliance](#project-compliance) +- [Secure development practices](#secure-development-practices) +- [Security issue resolution](#security-issue-resolution) +- [Appendix](#appendix) + +## Metadata + +| | | +| ----------------- | ----------------------------------------------------------------------------------------------------------- | +| Assessment Stage | Complete | +| Software | [Dragonfly](https://github.com/dragonflyoss/Dragonfly2) | +| Website | https://d7y.io | +| Security Provider | No | +| Languages | Go, Rust | +| SBOM | [FOSSA Scan](https://app.fossa.com/projects/git%2Bgithub.com%2Fdragonflyoss%2FDragonfly2/refs/branch/main/) | + +### Security links + +| Doc | url | +| ---------------------------- | ------------------------------------------------------------------ | +| Security file | | +| Default and optional configs | | + +## Overview + +Dragonfly provides efficient, stable, secure file distribution and image acceleration based on p2p technology +to be the best practice and standard solution in cloud native architectures. It is hosted by +the Cloud Native Computing Foundation(CNCF) as an Incubating Level Project. + +### Background + +Dragonfly 1.x has been open source in November 2017 and used in production environments by many companies. And joined +the CNCF as a sandbox project in October 2018. In April 2020, The CNCF Technical Oversight Committee (TOC) voted to +accept Dragonfly as an Incubating Project. In April 2021, Dragonfly 2.0 was released after architectural optimization and +code refactoring. + +Dragonfly provides efficient, stable and secure file distribution and image acceleration based on P2P technology +to be the best practice and standard solution in cloud native architectures. +It is designed to improve the efficiency and speed of large-scale file distribution and used in the fields of file distribution, +AI model distribution, cache distribution, log distribution and image distribution. + +With the production practice, Dragonfly based on P2P technology to accelerate the image is insufficient to support +faster container launching, such as the Function as a Service (FaaS). +Therefore, we created Nydus as a sub-project of Dragonfly to address this need +and [Nydus Snapshotter](https://github.com/containerd/nydus-snapshotter) become a sub-project of containerd +which is an external plugin of containerd for Nydus. +Nydus implements a content-addressable file system that enhances the current OCI image format with +faster container launch speed, better image space and network bandwidth efficiency, and end-to-end data integrity. + +### Actors + +Dragonfly services could be divided into four categories: Manager, Scheduler, Seed Peer and Peer. + +![arch](./images/arch.png) + +#### Manager + +- Stores dynamic configuration for consumption by seed peer cluster, scheduler cluster and client. +- Maintain the relationship between seed peer cluster and scheduler cluster. +- Provide async task management features for image preheat combined with harbor. +- Keepalive with scheduler instance and seed peer instance. +- Filter the optimal scheduler cluster for client. +- Provides a visual console, which is helpful for users to manage the P2P cluster. +- Clearing P2P task cache. + +#### Scheduler + +- Based on the multi-feature intelligent scheduling system selects the optimal parent peer. +- Build a scheduling directed acyclic graph for the P2P cluster. +- Remove abnormal peer based on peer multi-feature evaluation results. +- In the case of scheduling failure, notice peer back-to-source download. +- Provide metadata storage to support file writing and seeding. + +#### Client + +- Serve gRPC for `dfget` with downloading feature, + and provide adaptation to different source protocols. +- It can be used as seed peer. Turning on the Seed Peer mode can be used as + a back-to-source download peer in a P2P cluster, + which is the root peer for download in the entire cluster. +- Serve proxy for container registry mirror and any other http backend. +- Download object like via `http`, `https` and other custom protocol. +- Supports RDMA for faster network transmission in the P2P network. + It can better support the loading of AI inference models into memory. + +### Actions + +#### Download Task + +- Actors: Scheduler, Seed Peer, Peer +- Description: When downloading a task , the download request is proxied to Dragonfly via the Peer HTTP Proxy. + Peer will first register the Task with the Scheduler, and the Scheduler will check the Task metadata to + determine whether the Task is downloaded for the first time in the P2P cluster. If this is the first + time downloading, the Seed Peer will be triggered to download back-to-source, and the Task will be divided based + on the piece level. After successful registration, The peer establishes a connection to the scheduler based on + this task, and then schedule the Seed Peer to the Peer for streaming based on piece level. when a piece is successfully + downloaded, the piece metadata will be reported to the Scheduler for next scheduling. If this is not the first time + downloading, the Scheduler will schedule other Peers for the download. The Peer will download pieces from different Peers, + splices and returns the entire file, then the P2P download is completed. +- Security Checks: Peer HTTP Proxy should be protected from basic authentication and authorization. + Each piece of the task should be verified by the hash algorithm to ensure the integrity of the data. + The data transmission between the Peers has been encrypted to ensure the security of the + data when enable the security feature. + +#### Preheat Task + +- Actors: Manager, Scheduler, Seed Peer +- Description: Preheat task is a feature that allows users to preheat the task in the P2P cluster. The Manager + will first receive the preheat request from the client, and then the Manager will call scheduler to schedule + the Seed Peer to download the task back-to-source. After the task is downloaded, the Scheduler will record the + metadata of the task, and the Seed Peer will be scheduled to download the task to the Peer. +- Security Checks: The preheat task API in manager should be protected by the Personal Access Token (PAT) to + ensure the security. If user uses the console to preheat the task, user should login with the username and password + to access the console. The console integrated with the RBAC to control the user's access. + +#### Services Communication + +- Actors: Manager, Scheduler, Seed Peer, Peer +- Description: Services communication via gRPC. Peer and Seed Peer will call the Manager to update dynamic configuration. + Peer and Seed Peer will call the Scheduler to register the task and report the task status. Scheduler will call the + Seed Peer to download the task back-to-source. Peer exchange piece information with each other. +- Security Checks: The gRPC communication should be protected by the TLS to ensure the security of the data transmission. + +### Goals + +**General** + +- P2P technology: Based on P2P technology, use the idle bandwidth of Peer to improve download speed. +- Non-invasive: Non-intrusive support for multiple container runtimes, download tools, AI infrastructure, etc. +- Peer configuration: Load limit, concurrent limit, traffic limit, etc. can be configured. +- Consistency: Ensures downloaded files are consistent even if the user does not check for consistency. +- Exception isolation: Isolate exceptions based on Service level, Peer level and Task level to improve download stability. +- Ecosystem: Provides simple integration with AI infrastructure, container runtimes, container registry, + download tools, etc. + +**Security** + +- Data integrity: Ensure the integrity of the data by verifying the hash algorithm. +- Data transmission: Ensure the security of the data transmission by encrypting the data. +- Access control: Ensure the security of the access by the Personal Access Token (PAT). +- User authentication: Ensure the security of the user by the username and password. + +### Non-Goals + +**General** + +- Data Storage: Dragonfly does not store any data, it only caches the data temporarily. The data will be evicted after + the task reaches the expiration time. +- Data Visualization: Dragonfly does not provide data visualization, but provides a visual console to manage the P2P cluster. +- Container Runtime: Dragonfly does not provide container runtime, but provides a Nydus Snapshotter to + enhance the container launch speed. + +**Security** + +- Sensitivite Data: Dragonfly does not handle sensitive data, such as user's personal information, + user's password, etc. The data only caches the file data temporarily. +- Download Access Control: Dragonfly does not provide download access control, if you want to control the download + access, you need to control the access from the source side. + +## Self-Assessment Use + +This self-assessment is created by the Dragonfly team to perform an internal analysis of the project's security. +It is not intended to provide a security audit of Dragonfly or function as an independent assessment or +attestation of Dragonfly's security health. The document is intended to be used by the Dragonfly team to +identify areas of improvement in the project's security posture. + +## Security Functions and Features + +### Critical + +A listing critical security components of the project with a brief +description of their importance. It is recommended these be used for threat modeling. +These are considered critical design elements that make the product itself secure and +are not configurable. Projects are encouraged to track these as primary impact items +for changes to the project. + +- Transport-Layer Security (TLS): The services communication is encrypted by the TLS to ensure the security of the data transmission. + Dragonfly uses the OpenSSL library to provide the TLS support for the gRPC communication. +- Authentication and Authorization: The Peer HTTP Proxy should be protected from basic authentication and authorization. + The preheat task API in manager should be protected by the Personal Access Token (PAT) to ensure the security. + The console integrated with the RBAC to control the user's access. +- Data Verification: Each piece of the task should be verified by the hash algorithm(blake3) to ensure the + integrity of the data. +- Control Access: The console integrated with the RBAC to control the user's access for operating the P2P cluster, + dynamic configuration, preheat task, etc. + +### Security Relevant + +A listing of security relevant components of the project with +brief description. These are considered important to enhance the overall security of +the project, such as deployment configurations, settings, etc. These should also be +included in threat modeling. + +- Logging and Monitoring: Dragonfly provides the log and metrics for monitoring the P2P cluster. + The log and metrics can be used to monitor the P2P cluster, detect the abnormal behavior, and + analyze the performance of the P2P cluster. +- Dynamic Configuration: Dragonfly provides dynamic configuration for consumption by Seed Peer, + Scheduler and Peer. The dynamic configuration can be used to configure the P2P cluster, + such as load limit, concurrent limit, traffic limit, etc. If DDoS attack occurs, the dynamic configuration + can be used to limit the traffic of the P2P cluster. +- Scan and Analysis: Dragonfly uses the FOSSA to scan the dependencies of the project to ensure the security of the dependencies. + The FOSSA can be used to detect the vulnerabilities of the dependencies and provide the solution to fix the vulnerabilities. + +## Project compliance + +Dragonfly does not document meeting particular compliance standards. + +## Secure Development Practices + +### Development Pipeline + +All code is maintained on [Github](https://github.com/dragonflyoss/Dragonfly2). + +- Contributions and Changes + - Code changes are submitted via Pull Requests (PRs) and must be signed and verified. + - Commits to the main branch directly are not allowed. +- Code Review + - Changes must be reviewed and merged by the project maintainers. + - The code is reviewed by multiple members from various teams and then approved by all of the reviewers before + passing the check. +- Automated Testing + - In each PR, the code has to pass through various security checks and vulnerability analysis, to find if the code is + secure and would not fail basic testing. + - Tools like CodeQL and GoSec have been adopted for security scanning. + - The project utilizes various vulnerability tests, unit tests and neutral tests to quantify whether the changes + would be safe in basic context, before the reviews done by the project maintainers. +- Dependency Management + - The project regularly updates its dependencies and check for vulnerabilities and keeps its github + updated at all times asynchronously. + +### Communication Channels + +- Internal + - The Dragonfly team mostly uses platforms like GitHub, Slack, or email lists for internal communications within the teams. +- Inbound + - Users and contributors to the Dragonfly project can communicate with the Dragonfly team via GitHub issues, mailing lists, + CNCF and through Slack channels as well. +- Outbound + - The updates and announcements from Dragonfly are made through Dragonfly Blog, GitHub, CNCF mailing lists, + and social media channels. + +### Ecosystem + +Dragonfly is integrated with various cloud-native projects and container runtimes, such as containerd, Docker, CRI-O, etc. +It is widely used in the fields of file distribution, AI model distribution, cache distribution, +log distribution and image distribution. + +Reference to the first integrations that offer-first party support for Dragonfly is present here in [Integrations](https://d7y.io/docs/next/operations/integrations/container-runtime/containerd/). + +#### Image Acceleration + +Dragonfly supports various container clients such as containerd, Docker, cri-o, ORAS, etc. +It provides three solutions for image acceleration. The first solution is to use Dragonfly to distribute +images based on P2P technology, which is suitable for large-scale cluster. The second solution is to use Dragonfly and +Nydus to distribute accelerated images, which is suitable for large-scale cluster and faster container launching. +The third solution is to use Nydus to distribute accelerated images, which is suitable for faster container launching. + +Production practice and statistical data can refer to: + +- [Dragonfly integrates nydus for image acceleration practice](https://www.cncf.io/blog/2022/11/21/dragonfly-integrates-nydus-for-image-acceleration-practice/) +- [The evolution of the Nydus Image Acceleration](https://www.cncf.io/blog/2022/11/15/the-evolution-of-the-nydus-image-acceleration/) +- [Volcano Engine: distributed image acceleration practice based on Dragonfly](https://www.cncf.io/blog/2023/04/13/volcano-engine-distributed-image-acceleration-practice-based-on-dragonfly/) +- [Ant Group security technology’s Nydus and Dragonfly image acceleration practices](https://www.cncf.io/blog/2023/05/01/ant-group-security-technologys-nydus-and-dragonfly-image-acceleration-practices/) +- [Stable and efficient image distribution for 1 billion monthly users with Dragonfly](https://www.cncf.io/case-studies/kuaishou-technology/) + +#### File Distribution + +Dragonfly supports large-scale file distribution and uses P2P technology to eliminate the impact of +origin bandwidth limitations. It supports file distribution of protocols including HTTP, HDFS, etc. +Additionally, it also supports different object storage protocols includes S3, OSS, OBS, etc. + +Add [Dfstore](https://d7y.io/docs/concepts/terminology/dfstore) to expand the file distribution capability, +it can depend on different types of object storage, such as S3, OSS, OBS, etc. to provide stable object storage capabilities. +Dfstore uses the entire P2P network as a cache when storing objects. Depend on object storage as +the backend to ensure storage reliability. In the process of object storage, P2P cache is effectively +used for fast read and write storage. + +#### AI Infrastructure + +Dragonfly supports distributing data during AI training and AI inference. +In the AI inference, Dragonfly supports [Triton Server](https://github.com/triton-inference-server/server) and [TorchServe](https://github.com/pytorch/serve) +to use Dragonfly distribution model. In the AI training, [Fluid](https://github.com/fluid-cloudnative/fluid) downloads +dataset through Dragonfly when running based on [JuiceFS](https://github.com/juicedata/juicefs). + +There are many use cases in the community, using Dragonfly to distribute data based on P2P technology. +In the inference, the concurrent download model of the inference service can effectively relieve the bandwidth pressure of +the model registry through Dragonfly, and improving the download speed. Users can embed the model into the +accelerated image and use Dragonfly and Nydus for faster container launching. + +Production practice and statistical data can refer to: + +- [Dragonfly: Intro, Updates and AI Model Distribution in the Practice of Kuaishou - Wenbo Qi, Ant Group & Zekun Liu, Kuaishou Technology](https://sched.co/1PTJb) +- [Dragonfly helps Volcano Engine AIGC inference to accelerate image through p2p technology](https://mp.weixin.qq.com/s/kY6DxRFspAgOO23Na4dvTQ) +- [Get faster pull times with Nydus on CoreWeave](https://docs.coreweave.com/cloud-tools/nydus) + +## Security Issue Resolution + +### Responsible Disclosure Process + +Dragonfly has a security policy and process in place for responsible disclosure of security vulnerabilities, refer to the +[SECURITY.md](https://github.com/dragonflyoss/Dragonfly2/blob/main/SECURITY.md). + +- Security researchers can report vulnerabilities confidentially by emailing the Dragonfly maintainers at . +- Report the security issue with the detailed information, such as the description of the vulnerability, + the steps to reproduce the vulnerability through the . +- The Dragonfly maintainers will acknowledge the report within 48 hours and provide an estimated timeline for a fix. +- Patch releases are made available as soon as possible after the vulnerability is confirmed and a fix is available. + +### Incident Response + +The Dragonfly maintainers will respond to security incidents within 48 hours of being notified. In practice, +the response time is usually much faster. The Dragonfly maintainers will work with the reporter to understand +the issue and develop a fix. + +## Appendix + +### Known Issues Over Time + +There haven't been any known security issues in the project. If you find any security issues, +please report them tools like GitHub issues, mailing lists, CNCF and through Slack channels. + +### CII Best Practices + +Dragonfly has attained the Open Source Security Foundation(OpenSSF) Best Practices Badge, +refer to . + +### Case Studies + +- Volcano Engine - +- KuaiShou - +- Ant Group - +- CoreWeave - + +### Related Projects/Vendors + +- **Harbor** provides a registry for storing and distributing container images. It can be integrated with Dragonfly to + accelerate image distribution. Dragonfly will help Harbor to distribute images based on P2P technology in + a large-scale cluster. +- **Containerd** is a container runtime. Dragonfly integrates with containerd to provide + image acceleration and container launching based on P2P technology. Dragonfly will become an mirror for containerd + to intercept the image download traffic to accelerate the image download. If user uses Nydus Snapshotter, the containerd will + download image on-demand and launch container faster. +- **Docker** is a container runtime. Dragonfly integrates with Docker to provide image acceleration and + container launching based on P2P technology. Dragonfly will intercept the Docker image download traffic by HTTP Proxy + to accelerate the image download. From c5fe5b14a1fe9032e8eab6d1997f1f2c7cff8abd Mon Sep 17 00:00:00 2001 From: Krishna <82863+krishnakv@users.noreply.github.com> Date: Wed, 31 Jul 2024 23:27:52 +0530 Subject: [PATCH 3/7] Create joint-assessment for OpenFGA (#1289) --- .../projects/openfga/joint-assessment.md | 792 ++++++++++++++++++ 1 file changed, 792 insertions(+) create mode 100644 community/assessments/projects/openfga/joint-assessment.md diff --git a/community/assessments/projects/openfga/joint-assessment.md b/community/assessments/projects/openfga/joint-assessment.md new file mode 100644 index 000000000..b182501d9 --- /dev/null +++ b/community/assessments/projects/openfga/joint-assessment.md @@ -0,0 +1,792 @@ +# Joint-assessment Outline + +The joint-assessment is built on top of the [self-assessment.md](https://tag-security.cncf.io/assessments/projects/openfga/self-assessment/) to +collaboratively assess the current security state of a project. + +The burden is primarily on the proposing project to demonstrate it is secure in +a manner that is understandable to the broader community. The +reviewers will help to assess and probe the design and supporting project documentation. + +The proposing project must provide a written document that describes the project +and its security. In the case of OpenFGA, there is structured information present +in the [Security-Insights](https://github.com/openfga/openfga/blob/main/SECURITY-INSIGHTS.yml) page. The project [self assessment](https://github.com/cncf/tag-security/blob/main/community/assessments/projects/openfga/self-assessment.md) has been completed. + +Projects are encouraged to cross link additional supporting documents or details +from their repo into the self-assessment. + +## Joint-assessment of OpenFGA + +## Table of Contents + +* [Metadata](#metadata) + * [Security links](#security-links) +* [Overview](#overview) + * [Background](#background) + * [Goals](#goal) + * [Non-goals](#non-goals) +* [Joint-assessment use](#joint-assessment-use) +* [Intended use](#intended-use) +* [Project design](#project-design) + * [Functions and features](#functions-and-features) + * [Security functions and features](#security-functions-and-features) +* [Configuration and set-up](#configuration-and-set-up) +* [Project compliance](#project-compliance) +* [Security analysis](#security-analysis) +* [Secure development practices](#secure-development-practices) +* [Security issue resolution](#security-issue-resolution) + * [Closed security issues and + vulnerabilities](#closed-security-issues-and-vulnerabilities) +* [Hands-on assessment](#hands-on-assessment) +* [Roadmap](#roadmap) +* [Appendix](#appendix) + +## Metadata + +A table at the top for quick reference information, later used for indexing. + + + +| | | +| -- | -- | +| Assessment Stage | Complete | +| Software | [https://github.com/openfga](https://github.com/openfga) | +| Security Provider | Yes. OpenFGA is used to decide if a subject (user, application) user can perform a specific action on a resource or not.| +| Languages | Go, Java, Javascript, Python, C# | +| SBOM | The Software Bill of Materials is not publicly available, but is included in each GitHub release using Syft, which is a CLI tool, and Go library for generating an SBOM from container images and file systems, since [pull/683](https://github.com/openfga/openfga/pull/683) | + +### Security links + +These are link to existing security documentation for the project. + +| Doc | url | +| -- | -- | +| Security Policy | [OpenFGA Security Policy](https://github.com/openfga/openfga/security/policy) | +| Security Insights | [OpenFGA Security Insights](https://github.com/openfga/openfga/blob/main/SECURITY-INSIGHTS.yml) | +| Security risks | [OpenFGA Security risks](https://github.com/orgs/openfga/security/risk) | +| -- | -- | + +## Overview + +The overview sections are pulled from the [self-assessment](https://tag-security.cncf.io/assessments/projects/openfga/self-assessment/) and updated. + +Implementing access control and authorization is a requirement when developing secure and compliant applications, to explicitly check permissions +such that a subjects can perform authorized actions on specific resources. + +OpenFGA is a high performance and flexible authorization/permission engine that can be used to implement fine grained access control in any +application component. + +Developers can use OpenFGA to craft authorization and permission policies based on the resource access and authorization model +specific to their own project(s). They can further use the APIs provided by the project to confirm users have the permissions +required to access a given resource. + +### Background + +OpenFGA is an authorization/permission engine that incorporates Relationship-Based Access Control (ReBAC) and Attribute Based Access Control (ABAC) +concepts with a domain-specific language that enables crafting authorizations solutions that can grow and evolve to any use case. + +Its inspired on the idea described in the [Google Zanzibar paper](https://research.google/pubs/pub48190). + +Fine-Grained Authorization refers to individual users having access to specific objects and resources within a system. Google Drive is an example of this, +as owners of resources can grant different users to have different levels of access to their resources. + +OpenFGA makes helps developers make authorization decisions by combining two concepts: + +- An Authorization Model, where developers define their authorization policies + +- A set of relationship tuples that instantiate the model and OpenFGA uses to answer access control queries. + +An authorization model looks like: + +```python +model + schema 1.1 + +type user +type group + relations + define member: [user] +type folder + relations + define owner: [user] + define parent: [folder] + define viewer: [user, group#member] or owner or viewer from parent + +type document + relations + define parent: [folder] + define owner: [user] + define viewer: [user, group#member] or owner or viewer from parent +``` + +Relationship tuples look like: + +| Subject | Relation | Object | +| --- | --- | --- | +| user:alice | member | group:engineering | +| folder:root | parent | document:readme | +| group#engineering:member | viewer | folder:root | + +With this information, OpenFGA can be queried in different ways: + +- Using the [/check](https://openfga.dev/api/service#/Relationship%20Queries/Check) endpoint to ask questions like "Is `user:alice` a `viewer` for `document:readme`?". With the data provided above, OpenFGA will return `{allowed : "true"}`, as Alice is a member of the engineering team, which has viewer access on the 'readme' document's parent folder. + +- Using the [/list-objects](https://openfga.dev/api/service#/Relationship%20Queries/ListObjects) endpoint to ask questions like "What are all the documents for which `user:alice` is a `viewer`. With the data provided above, OpenFGA will return `{object_ids { "document:readme" }` + +### Goal + +- Simplify and standardize authorization processes, making them more consistent across various applications and systems. + +- Establish patterns and standards for externalized authorization. + +- Create architectural patterns, terminologies, and protocols that enable interoperability among different authorization systems. + +- Deliver an authorization service for any application component. + +- Enable centralized authorization decisions and permits diverse teams to implement authorization using a shared framework across various application components. + +### Non-goals + +- Tools for management of groups/roles/permissions not inherently provided to the end-users. + +- Does not intend to serve as a comprehensive data repository for non-authorization related data. + +- Does not aim to provide a complete authentication and Access Control Solution. + +## Joint-assessment use + +The joint-assessment is initially created by the project team and then +collaboratively developed with the security reviewers as +part of the project's TAG-Security Security Assessment (TSSA) Process. +Information about the TAG-Security Review can be found in the [CNCF TAG-Security +Review Process Guide](https://tag-security.cncf.io/assessments/guide/). + +This document does not intend to provide a security audit of OpenFGA and is +not intended to be used in lieu of a security audit. This document provides +users of the project with a security focused understanding of OpenFGA and, when +taken with the [self-assessment](./self-assessment.md), provide the community with +the TAG-Security Review of the project. Both of these documents may be used and +referenced as inputs to a separate security audit. + +OpenFGA is a project that provides a security service and as such, any defect +in the project may be a security issue. This document does not look to enumerate +all the possible quality issues (e.g. undetected circular references in model +definitions) that could lead to security issues for users of OpenFGA. + +Taken together, this document and the [self-assessment](./self-assessment.md) serve as a +context for the TOC and community when OpenFGA seeks graduation and is preparing for a security audit. + +## Intended Use + +* Target Users and Use Cases. The key users of this project are users who define authorization models, application developers that integrate the API + into their application for externalizing authorization and operators. + + OpenFGA can be used in any environment and has helm charts defined for install on a Kubernetes platform. + 1. OpenFGA is used by applications to externalize authorization decisions + 2. The project implements the [Google Zanzibar paper](https://research.google/pubs/pub48190) paper for effective, performant authorization + 3. Administrators can program authorization models into the system for use by application teams + +* Operation. OpenFGA supports both MySQL and Postgres as its datastore. An in-memory store is implemented as the default. + +## Project Design + +* Design. OpenFGA provides rich documentation around its core [concepts](https://openfga.dev/docs/concepts) and usage of the project. Some project + decisions are documented under the [rfcs repository](https://github.com/openfga/rfcs), however, this does not have a comprehensive list of all + project decisions. + +### Functions and features + +The list below describes the functionality provided by OpenFGA. This assessment +did not segregate these into critical and other levels but focused on the server +component as a priority. + +```yaml +actions: + system.users: + - Request access to [system.resources] through [openfga.clients|system.applications] + + system.developers: + - Integrate [openfga.sdks] in [openfga.clients|system.applications] + - Validate and verify semantically [openfga.authz_models] + + system.operators: + - Migrate [openfga.datastore] + - Deploy [openfga.server] + + system.external.idp: + - Provide [jwks_uri] through oidc /.well-known/openid-configuration + - Sign [token] with [rs256] algorithm + + openfga.language: + - Provide a domain specific language to describe authorization policies + - Describe the authorization model with [types], [relations] and [conditions] + + openfga.datastore: + - Store authorization models [openfga.authz_models] + - Store authorization data [openfga.relationships.tuples] + - Support for [MySQL, Postgres] database + + openfga.clients|system.applications: + - Authenticate against [openfga.server] with [openfga.psk] secret or through [external.idp] + - Execute authorization checks with [openfga.relationships.queries] + - Manage the authorization model [openfga.authz_models] + + openfga.server: + - Write authorization model [openfga.authz_models] to [openfga.datastore] + - Write authorization data [openfga.relationships.tuples] to [openfga.datastore] + - Provide [grpc|http] messaging protocol + - Authenticate trusted [openfga.clients] with 3 options [none|psk|oidc] + - Validate and verify [payload] + - Evaluate access control decisions [openfga.relationships.queries] + + openfga.server.api: + stores: + - list + - create + - get + - delete + - assertions.read + - assertions.upsert + authz-models: + - list + - create + - get + relationships.tuples: + - read + - write + - delete + - list.changes + relationships.queries: + - check + - expand + - list-objects + - streamed-list-objects + - list-users +``` + +#### Security functions and features + +OpenFGA, as an Open-Source project, requires the community to review and evaluate the security implementation per the Principle of Open Design. + +OpenFGA models authorization systems by providing authorization methods such as Role-based Access Control, Relationship-based Access Control and Attribute-based Access Control. + +OpenFGA was designed for speed in processing secure authorization check call. This swift authorization mechanism not only enhances efficiency +but also reinforces the security posture, assuring robust protection for applications and platforms for diverse scales. + +OpenFGA provides a wide variety of SDKs, as well as easy API integration for new SDKs. + +## Configuration and Set-Up + +* Default. The default configuration of the project is described under the [getting started](https://openfga.dev/docs/getting-started) section of the documentation. + +* Secure. The recommended [production configuration](https://openfga.dev/docs/getting-started/running-in-production) of the project is described under a + separate part of the documentation. It is not explicitly secure by default. + +## Project Compliance + +There are no specific security standards or sub-sections the project is documented +as meeting (e.g. NIST 800-53, CSA, etc.). + +### Existing Audits + +A self-assessment has been performed but there are no project audits currently +for OpenFGA. + +## Security Analysis + +### Attacker Motivations + +OpenFGA is an authorization/ permission engine that secures sensitive information +including users of the systems referenced by the permission model as well as +permissions and access levels for each. Attackers may have multiple motivations +including: +* Exfiltrating relationship, condition and user data from the service +* Tampering with data to assign, elevate permissions or remove access to authorized users +* Studying the data to understand the application design and operation for further attack steps +* Denial of service by rendering OpenFGA unable to respond to auth requests + +### Predisposing Conditions + +There are multiple potential configurations of the project that could be exploited, +this includes permissive settings for API tokens and other secrets, running the +server in elevated/privileged mode, exposing vulnerable endpoints such as the profiler accessible to +an attacker and exfiltration of secret tokens from interfacing applications and CLI. + +In addition vulnerabilities may be discovered in the server code or dependent libraries +that can be exploited by an attacker. + +### Expected Attacker Capabilities + +While the attacker is not expected to possess the capability to break well-known +encryption standards, eg AES256, or hashes such as SHA256, they will have sufficient capabilities +and motivation to use well-known tools and techniques for their work. Attackers +are not just assumed to be external to the OpenFGA project, or client application vendor/project, but may also +be insiders who are contributors, maintainers, or repo admins, or developers or operators with privileged access +inside the client application environment that are looking to gain a foothold for +further exploits. The latter scenarios assume that the attacker has breached or already has access through +several layers of defense and has direct access to OpenFGA components and +endpoints to further their position within the company perimeter. + +### Attack Risks and Effects + +While not storing PII (as per project recommendations), OpenFGA does have sensitive +information pertaining to the application and permissions within +the organization. This data could be used by attackers to better understand +the attack landscape and also perform more destructive actions such as escalating +their permissions and locking out users from system access. + +### Security Impact Assessment + +A compromise of the OpenFGA server in production would lead to +downstream effects in the application landscape. Attackers could assign +themselves arbitraty permissions to sensitive resources or data and also lock out +legitimate users. This could lead to effects from a denial of service +and degradation of customer experience to exfiltration of critical data +from sensitive systems. OpenFGA deals directly with authorization and is +a critical part of any application, as such, compromising this system +could have catastrophic consequences to the organization. + +#### Security Risks and Security Impact of Using/Operating OpenFGA +- Access Control: OpenFGA by definition is designed to enforce: (i) information system access to authorized users, or + processes acting on behalf of authorized users or devices (including other information systems); + and (ii) the types of transactions and functions that authorized users are permitted to exercise. As such, a failure + in either access to OpenFGA data or code itself, or the functioning of OpenFGA exposes the application to critical access + control risks. +- Awareness and Training: Using OpenFGA will requrire developer, operator, security team, auditor and end user training to ensure + that personnel are adequately prepared to deploy, maintain, and use OpenFGA and design appropriate relationships and models. + Security staff need to understand the failure modes and threat model and how to monitor the components and produce audit artifacts. + Even end users need to understand how permissions are modeled and managed, for example, understanfing Google Drive permissions can have a steep + learning curve for those used to more traditional RBAC rules found in Windows or Linux file systems. +- Audit Support: Introducing OpenFGA will impact system/application audit requirements and require OpenFGA developers, app developers, + and operators to consider how to: + - create, protect, and retain information system audit records to the extent needed to enable the monitoring, analysis, investigation, + and reporting of unlawful, unauthorized, or inappropriate information system activity; and + - ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions. +- Change Management: OpenFGA project developers and app developers need to consider how changes to the OpenFGA code, configuration, model syntax and features, + and the application's specific model(s) will impact the: + - baseline configuration and relate to the current inventory of organizational users, resources, and condition attributes; + - establishment and enforcement of secure configuration settings of the OpenFGA components and the app using OpenFGA; and + - ability to monitor and control changes to the baseline configurations of the specific app models and to the OpenFGA components +- Identity: How will change(s) to the underlying Identity Provider(s) and identity establishment impact how OpenFGA: + - identifies users, processes acting on behalf of users, or other subjects (eg IoT devices, etc.); and + - authenticates (or verifies) the identities of those users, processes, or devices, as a prerequisite to allowing access. +- Maintenance: How will periodic and timely maintenance be performed including critical security patches in OpenFGA's code and dependencies; + how will the project and the app developers provide effective controls on the tools, techniques, mechanisms, and personnel performing maintenance + of the OpenFGA code and apps using it. For example, how would the project control for a malicious contributor trying to subtly introduce leaks or + back doors? How would app developers identify these potential flaws? How is the repo secured and maintained over time? Other dependencies? etc. +- Securing Data In Transit, At Rest and In Use: While OpenFGA doesn't directly implement encryption, authentication, or integrity of data flows, + the maintainers and devs using OpenFGA must consider: + - communications (i.e., information transmitted or received by OpenFGA components, and the app) are monitored, controlled, and protected at the + internal and external boundaries; eg encrypting communication between OpenFGA and the database, or the shared keys, or the audit logs, etc. and + - architectural designs, software development techniques, and systems engineering principles that promote effective data security are implemented +- Risk Assessment and Vulnerability Management: How will OpenFGA maintainers and app devs and operators define how: + - OpenFGA and SDK flaws are identified, reported, and corrected in a timely manner; + - malicious code protection is employed; + - component and OpenFGA app related events are monitored and detected; + - the correct configuration and operation of security features is tested and verified; + - information is checked for accuracy, completeness, validity, and authenticity. This is especially imporant in verifying and testing the model + syntax and semantics +- Supply Chain Integrity and Attacks: How will risks related to OpenFGA itself, and its dependencies be assessed and tracked and remediated? +- Incident Response, Disaster Recovery, Continuity, SRE: How will use of OpenFGA affect existing plans for responding to, investigating, and remediating + incidents - whether security or availability related? What playbooks should be created specific to OpenFGA failure modes or attacks? What alerts are + useful? What forensic data is required? How are logs collected, aggregated, correlated, and retained? +- Compliance and Regulatory Requirements: What documentation, processes, approvals, and legal requirements are in scope for either certification or audit + by a 3rd party or government agency or customer? + +#### Failure Modes Considered + +- Project/Repo/Code Failures + - Key admins or maintainers abandon the project or are unavailable + - The repository is deleted or defaced or compromised + - Bugs exist in the core validation of the relationships and conditions + - Bugs exist in the dependencies used + - Leakage of data in the logs or by contacting existing services + - Timing attacks, side channel telemetry + - shared key or OIDC TLS cert compromises (is OSCP or CRL being checked?) + - Lack of, or insecure use of, cryptographic code or protocols + - Release process failures + - Failures to respond to, or analyze, reported vulnerabilities or known exploits + - Malicious developers injecting malicious code or designs +- Developer/App Design Failures + - incorrect use of OpenFGA outside its intended design/goals + - incorrect confiuration of OpenFGA store, keys, certs, etc + - incorrect definition of app code using OpenFGA to check relationships, conditions + - incorrect or missing error handling code or corner cases + - logging or leaking sensitive information + - lack of stress and performance testing + - not using the latest secure releases +- OpenFGA/App Operations Failures + - failure to check the provenance and integrity of code used + - failure to check the provenance and integrity of confiuration used + - failure to check the provenance and integrity of model(s) used + - failure to secure keys, OIDC TLS, or database encryption and access control and auditing + - failute to plan for continuity and disaster recovery + - failure to plan for security incident response + - OpenFGA API service unavailable at runtime, either failing in a secure closed way, or due to DoS attack + - Store database unavailable at runtime, either failing in a secure closed way, or due to DoS attack + - Capacity planning for the service, networking, and database + - Messaging and communications to end users in the case of outages or failures or breach + +### Compensating Mechanisms + +Compensating mechanisms are covered in detail in the [Threat Model](#threat-model) +section. These cover steps such as architecture changes for a more +fine-grained permissions system, hardening the default deployment +instructions, changes to user documentation and changes in functionality to +address common exploits. + +## Threat Model + +Threat modelling was done by threat hunting using the MITRE Att&ck framework. Findings are listed below +along with the Att&ck technique associated with the finding. The findings +are categorized into logical sections. The values for the **Impact** and **Likelihood** +ratings can be High, Med or Low. + +NOTE: The OpenFGA server code is managed separately from the "language" parser code. +This review focused on the server code, and so a separate review (perhaps formal modeling exercise) +would be beneficial for the "language" parser project. As such language parser threats/attacks +should be considered outside the scope of this review. + +Opportunities for improvement identified include: + +- Implement FGA for server API +- Relook at user-defined API tokens as an authentication mechanism for API +- Make all installation scripts "secure by default" +- Validate best practices such as using strong API token and avoiding PII + +Further opportunities for improvement are listed under the [Secure Development](#security-hygiene-and-secure-sevelopment-practices) section. + +### Methods of authentication for server API + +Access to OpenFGA API is via oauth or pre-determined API tokens. Pre-shared +tokens present several weak points that result in the findings below. + +The project recommends oauth for secure authentication to the API. The recommendation +is to mark shared API tokens as a relatively insecure method of authentication and +that his be avoided in a production environment. This recommendation can be +updated both in the documentation as well as a WARNING can be emmitted in the logs +when authentication via shared API tokens is enabled. + +The recommendation to enable Fine Grained Authorization for the API is being +implemented under a [project issue](https://github.com/openfga/roadmap/issues/30). +This risk is currently being mitigated by OpenFGA users by proxying requests +and performing authorization on the proxy. + + +|Summary|When authenticating using pre-shared keys, these are exposed in container env vars.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Env vars are accessible to anyone with access to the container. There cannot be further permissions set on these like files. Keys further give access to stores and models.| +|MITRE classification|TA0001: Initial Access -> T1078: Valid Accounts
TA0003: Persistence -> T1078: Valid Accounts
TA0004: Privilege Escalation -> T1078: Valid Accounts| +|Actors|openfga.server| +|Suggested Mitigation|Secrets mounted in filesystem can be restricted with permissions. Alternatively,
SPIFFE/ Spire integration may offer a much high level of security (specifically using x.509 SVIDs).| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|Authenticating with shared keys allows keys to be added to the list.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Shared API keys are open to manipulation and bruteforcing since they are fixed keys.| +|MITRE classification|TA0003: Persistence -> T1136: Create Account| +|Actors|openfga.server| +|Suggested Mitigation|Being able to manipulate keys in the container requires access to container. However, impact will be high as openfga access will allow attackers to assign themselves arbitrary privileges.
Mitigations include, the ability to rotate keys on a frequent basis and forcing these API tokens to be mounted as files (can be permission controlled) instead of environment variables. Don't use shared keys. Use OAuth or SPIFFE.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|The openfga API endpoint does not support fga, so admins can modify models they may not own.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Broad permissions allow an admin to modify any model, not just ones that they own.| +|MITRE classification|TA0042: Resource Development -> T1585: Establish Accounts| +|Actors|openfga.server| +|Suggested Mitigation|Can the API endpoint for openfga server support more fine grained permissions so that only owners of stores/ models can modify them? Permissions can be set at a module level.
This is being implemented under this [issue](https://github.com/openfga/roadmap/issues/30) by the project.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + + +### Setting secure defaults for install + +This section has findings related to default install options that can be made more +secure. The artifacts analysed in this section include the helm chart for installation +and default configuration options. + + +|Summary|Open playground link - clients can access the playground (enabled by default) without authorization and access openfga models.| +|--|--| +|Discovered in self-assessment?|Yes| +|Weakness|Unauthorized access to openfga data. Ability to both view and manipulate data.| +|MITRE classification|TA0043: Reconnaissance -> T1595: Active Scanning
TA0001: Initial Access -> T1189: Drive-by Compromise| +|Actors|openfga.server| +|Suggested Mitigation|Already bring addresed by project team - https://github.com/openfga/roadmap/issues/7.
Documentation is clear to disable playground for prod deployments.
When enabled, the playground can be accessed only from localhost. Thus, the attacker must have access to the host where the server is running.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|Helm chart runs containers with higher privilege by default.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Unauthorized access to openfga data. Ability to both view and manipulate data.| +|MITRE classification|TA0002: Execution -> T1203: Exploitation for Client Execution
TA0003: Persistence -> T1098: Account Manipulation
TA0004: Privilege Escalation -> T1548: Abuse Elevation Control Mechanism
TA0004: Privilege Escalation -> T1134: Access Token Manipulation
TA0004: Privilege Escalation -> T1098: Account Manipulation
TA0004: Privilege Escalation -> T1611: Escape to Host
TA0005: Defense Evasion -> T1548: Abuse Elevation Control Mechanism
TA0005: Defense Evasion -> T1134: Access Token Manipulation| +|Actors|openfga.server| +|Suggested Mitigation|Could the defaults for all install scripts be set to run the openfga server with limited permissions?
In the case of helm chart, this would achieve:
  1. Not running server as root
  2. Not allowing privilege escalation
  3. Not allowing access to system calls unless required
  4. Setting filesystem to readonly
  5. Limiting access to mounted filesystems

This would greatly reduce the attack surface area. | +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|An external dependency to groundnuty/k8s-wait-for is pinned using tag.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Source tags can be overwritten in case of a supply chain attack and a compromised image may be pulled down. The risk is greater in the case of external, third party dependencies not under the projects control.| +|MITRE classification|TA0001: Initial Access -> T1195: Supply Chain Compromise| +|Actors|openfga.server| +|Suggested Mitigation|Pin the dependency using SHA tag for the container image.| +|Impact (High/ Med/ Low)|Low| +|Likelihood (High/ Med/ Low)|Low| + +### Other findings + +This section has other findings that could not be classified +in earlier parts. It includes exploits such as server DDOS and +potential leakage of information about application landscape. + +|Summary|INFORMATIONAL: Fixed API access tokens are susceptible to brute force attacks.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Having a fixed set of API tokens with no set TTL to rotate allows attackers to brute-force user created API tokens.| +|MITRE classification|TA0006: Credential Access -> T1110: Brute Force| +|Actors|openfga.server| +|Suggested Mitigation|Support for rotation may mitigate the impact. Also, is this to be disabled in production? Also, can there be a minimal requirement for length and entropy that the server checks for API tokens?
SPIFFE/ Spire integration may offer a much high level of security| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Med| + +|Summary|INFORMATIONAL: Playground link as well as shape of API identifies the openfga server.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|An attacker performing reconnaissance will be able to identify if a service is the openfga server, a high-value target.| +|MITRE classification|TA0043: Reconnaissance -> T1592: Gather Victim Host Information| +|Actors|openfga.server| +|Suggested Mitigation|Not sure if there is a remediation, given it’s the case for any API server that endpoints will return a 403 rather than 404 for unauthenticated access. An attacker iterating through the expected shape of the API will be able to identify an openfga server.| +|Impact (High/ Med/ Low)|Low| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|INFORMATIONAL: Usage of PII as part of Tuples.| +|--|--| +|Discovered in self-assessment?|Yes| +|Weakness|PII can be exfiltrated if present as a part of the Tuples.| +|MITRE classification|TA0042: Resource Development -> T1586: Compromise Accounts| +|Actors|openfga.server| +|Suggested Mitigation|Specifically called out in documentation that PII is not to be used as a part of tuples but not enforced.
Also, many sites will use email ID as primary login, documentation may need to address how to handle this situation.
A change to detect PII such as email ID's as part of relationships/ tuples and warn the user may tackle this finding at a code level.| +|Impact (High/ Med/ Low)|Med| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|INFORMATIONAL: Turning off audit logs will let an attacker mask operations on the server.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Allowing audit logs to be turned off completely via configuration would allow attackers to mask their trail.| +|MITRE classification|TA0005: Defense Evasion -> T1562: Impair Defenses| +|Actors|openfga.server| +|Suggested Mitigation|A possible mitigation is to log a warning message when logs are completely turned off?| +|Impact (High/ Med/ Low)|Med| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|INFORMATIONAL: DDOS attack on openfga server would impact overall application landscape.| +|--|--| +|Discovered in self-assessment?|Yes| +|Weakness|A DDOS attack on the server endpoint is not handled by the server and will result in widespread impact on all dependent applications.| +|MITRE classification|TA0005: Defense Evasion -> T1562: Impair Defenses| +|Actors|openfga.server| +|Suggested Mitigation|Documentation can be created for production configuration using an API Gateway/ other DDOS prevention mechanism.
The likelihood is rated low as OpenFGA is designed to be run within an intranet environment and not exposed to public internet.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +|Summary|INFORMATIONAL: Further review needed on tuple evaluation and crypto guarantees.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Potential ordering and collision attacks possible.| +|MITRE classification|[TA0004](https://attack.mitre.org/tactics/TA0004/): Privilege Escalation | +|Actors|openfga.server| +|Discussion| There seem to be minimal/no guarantees on order of permission tuples when evaluated, combined with not truly random ids, might lead to various timing/sequencing attacks. Nation states, sophisticated attackers, and insider attackers, may have elevated privileges but might not want to directly attack the OpenFGA server in a detectable manner. They may also want to stealthily stage capabilities for future attacks and remain undetected and evade forensic analysis. These attackers will look for more complex attacks that are harder to detect. Object and tuple ids are not guaranteed to be cryptographically random, nor are there cryptographically strong assurances of object/tuple content, so collisons may be craftable by attackers and thus the combo of malicious insertions and collision crafting could potentially lead to attcks where a malicious tuple that allows an unauthorized action replaces the correct expected tuple, or malicious tuples are inserted in different orders. For example when a tuple is written to storage it deletes an existing tuple with the same unique id. If an attacker can craft collisions they might be able to subtly replace a good tuple with a malicious tuple. Also there is a tuple iterator "continuation token". The server uses the continuation token so that it does not "have to restart from scratch on system restart or on error". This seems also succeptible to specially crafted attacks where changes can be introduced that make insertion and collision attacks possible. More review and testing and ideally formal validation would be needed to prove that such insertion and collision attacks are impossible. Review of all code comments in the golang crypto libraries used, and support of true random number generation would be appropriate for high security environments. Given the limited time available, neither empirical testing nor formal analysis was possible. This should be a focus for further (post-doc/intern funding?) testing and review.| +|Suggested Mitigation|Ensure true random ids, add model/tuple/object hashes or signatures, enforce strict ordering guarantees to ensure evaluation in order, and add crypto safe uniqueness guarantees to make collision insertion attacks impossible.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + + +|Summary|INFORMATIONAL: AES and SH256 crypo use is subject to side channel attacks and speculative execution attaks.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|golang crypto lib AES256-GCM + SHA256 hashing of key material used by encryptor function is subject to side channel attacks and speculative execution attacks.| +|MITRE classification|TA0006: Credential Access -> T1110: Brute Force| +|Actors|openfga.server| +|Discussion|The golang AES GCM code says "If you want to convert a passphrase to a key, use a suitable package like bcrypt or scrypt." Simply hashing a secret and using that as a key is not sufficient. A good overview id [discussed here.](https://crypto.stackexchange.com/questions/68545/aes-why-is-it-a-good-practice-to-use-only-the-first-16-bytes-of-a-hash-for-encr). In short, hashes are specially designed for (quick) hashing, key derivation functions are designed specially and carefully for key derivation. Don't mix those use scenarios up. Further, while golang [has some special options](https://github.com/golang/go/wiki/Spectre/dac828df865fc0eb0fed2b7c477ef2c7863ee17d) - not compiled by default - for minimal defenses, golang's crypto package is not specifically defensive against side channel and [speculative execution](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/mitigate-timing-side-channel-crypto-implementation.html) [attacks](https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf). While this is not an OpenFGA specific weakness, given the central importance of an authorization service, it is easy to presume that attackers, especially nation state or inside attackers, would focus energy on the OpenFGA service and use these techniques. Using hardware crypo offloading and also hardening OpenFGA and contributing upstream crypto and golang hardening would improve the overall robustness.| +|Suggested Mitigation|Use a proper key derivation function for converting key material to an actual key for AES-GCM, eg. Argon2 or PBKDF. Support hardware offloading of all crypto operations. Review defensive recommendations for software side-channel and speculative execution attacks.| +|Impact (High/ Med/ Low)|High| +|Likelihood (High/ Med/ Low)|Low| + +## Security Hygiene and Secure Development Practices + +This section addresses questions related to project-level security decisions. + +|Summary|Core maintainers are all currently from Okta.| +|--|--| +|Discovered in self-assessment?|No| +|Weakness|Dependence on a single organization can impact governance and long term leadership of the project.| +|MITRE classification|N/A| +|Actors|N/A| +|Suggested Mitigation|CNCF should provide resources and support for the project to recruit and train additional maintainers who can both help improve security and participate longer term in project governance and design leadership. Additionally, CNCF member companies who use OpenFGA should consider investing staff time and funds to OpenFGA governance and security.| +|Impact (High/ Med/ Low)|N/A| +|Likelihood (High/ Med/ Low)|N/A| + +Opportunities for improvement include: + +- Multi-organizational ownership of security reporting +- A roadmap that demonstrates a strong consideration for security features +- Public documentation of the project's release versioning policy / Easily understandable release process +- Public release of security and vulnerability scans, eg. Snyk, after appropriate embargo + +### Release and Update Process + +#### Release Documentation + +| Aspect | Status | +|-------------------------------------|--------| +| Easily understandable release process | GitHub Actions Workflow `release.yml` is used for GitHub releases. Action fails but release succeeds. | +| Release versioning policy | Reportedly in progress. | + +#### Provenance Artifacts + +Artifacts included with each release: + +- Checksums +- Checksum.sig/pem +- in-toto + +#### User Instructions for Validating Artifact Signatures + +| Aspect | Status | +|---------------------------------|--------| +| Clear instructions are provided | Yes | +| Instructions are maintained independently from the release process. | [OpenFGA Provenance Implementation](https://github.com/openfga/community/blob/main/provenance-implementation/openfga.md) | + +### Reporting Security Incidents + +#### Security Reporting Method +| Aspect | Status | +|----------------------------|--------| +| Documentation Location | Project’s Security tab | +| Email | [security@openfga.dev](mailto:security@openfga.dev) | +| SLA | 5-day | +| Visibility Test Response | 2 minutes | + +#### Security Reporting Ownership + +| Aspect | Status | +|-------------------------------|--------------------------------------------| +| Bus-Proofing | Checked by at least 2 users, available to more | +| Layoff-Proofing | Not implemented; core maintainers are all currently from Okta | + +### Reducing Vulnerabilities Through Development + +| Aspect | Details | +|--------|---------| +| Secure Development Practices | Optional secure development training is provided by Okta. | Security Review is done for every feature addition. | +| Code Quality and Testing | CodeQL is used on every pull request. The team is confident in the test coverage. | +| Binary Management | CLOMonitor check passes, and the team is aware of the dangers of allowing binaries in the project. | +| OpenSSF Scorecard | Badge present. Score is 9.3, well above the average of 4. | +| OpenSSF Best Practices | Badge present. Passing grade. | +| CLOMonitor | 100% security score. | + +### Dependency Management + +| Aspect | Status | +|-----------------------------|--------| +| Lifecycle Policy | [Dependency Lifecycle Policy](https://github.com/openfga/openfga/blob/main/docs/dependencies-policy.md) | +| SCA Checks | - [Semgrep Workflow](https://github.com/openfga/openfga/blob/main/.github/workflows/semgrep.yaml)
- [Pull Request Workflow](https://github.com/openfga/openfga/blob/main/.github/workflows/pull_request.yaml)
- Dependabot | +| SCA Findings Review Process | Recommendations from Dependabot, Snyk, etc., are reviewed during a weekly meeting | + +### Security Champions + +The following maintainers take a special interest in project security: + +- Louis Jette +- Maria Ines Parnisari + +### Roadmapped Security Improvements + +- Increase OpenSSF Best Practices badge level. +- Implement a singleflight CheckResolver to avoid concurrent evaluation of overlapping subproblems. [#1301](https://github.com/openfga/openfga/issues/1301) + +## Security Issue Resolution + +### Responsible Disclosure + +OpenFGA vulnerability management is described in the official project security documentation [SECURITY.md](https://github.com/openfga/.github/blob/main/SECURITY.md). + +### Incident Response + +The OpenFGA maintainers bear the responsibility of monitoring and addressing reported vulnerabilities. Identified issues undergo prioritized triage, with immediate escalation upon confirmation. The triage process is conducted in private channels. + +Adhering to the GitHub security advisory process, OpenFGA initiates the CVE (Common Vulnerabilities and Exposures) request upon issue identification. The resolution is developed in a private branch associated with the CVE. + +Upon confirmation of the fix's effectiveness, it is released through a new patch for each major supported version of OpenFGA. + +The changelog will link to the CVE, which will describe the vulnerability and its mitigation. Any public announcements sent for these fixes will be linked to [the release notes](https://github.com/openfga/openfga/releases/tag/v1.3.2). + +All OpenFGA security issues can be found on the [Github advisories page](https://github.com/openfga/openfga/security/advisories). + +### Closed security issues and vulnerabilities + +At the time of the joint assessment, OpenFGA listed closed issues under the +[security](https://github.com/openfga/openfga/security) tab of the OpenFGA repo. + +## Hands-on assessment + +The hands-on assessment is a lightweight review of the project's internal security as +well as the current recommendation configuration, deployment, and interaction +with regard to security. Hands-on assessments are subject to security reviewer +availability and expertise. They are not intended to serve as an audit or +formal assessment and are no guarantee of the actual security of the project. + +**OpenFGA did not receive a hands-assessment from TAG-Security.** + + + +## Roadmap + +* Project Next Steps. The team has created a [project](https://github.com/orgs/openfga/projects/8) under the OpenFGA organization to +track remediations for the findings from this joint assessment. The required +fixes are being undertaken by the project team. +* CNCF Requests. In the initial draft, please include whatever you believe the + CNCF could assist with that would increase security of the ecosystem. + +## Appendix + +* Known Issues Over Time. Past issues that have been publicly reported are listed +under [security issues](https://github.com/openfga/openfga/security) tab in the repository. This is not +a comprehensive list of all security issues. + +### Case Studies + +The [list](https://github.com/openfga/community/blob/main/ADOPTERS.md) of projects that utilize OpenFGA include Okta FGA, Twintag, Mapped, Procure Ai,Canonical (Juju & LFX), Wolt, Italarchivi, Read AI, Virtool, Configu, Fianu Labs, and ExcID. + +### Related Projects/Vendors + +The list of related projects is available as a [community resource](https://github.com/openfga/community/blob/main/related-projects.md) From affa4624cda22a26295b8b9c3c6cff6f129b3465 Mon Sep 17 00:00:00 2001 From: Justin Cappos Date: Wed, 31 Jul 2024 16:29:54 -0400 Subject: [PATCH 4/7] Update joint-review.md (#1329) Fixing broken links in the issue template Signed-off-by: Justin Cappos --- .github/ISSUE_TEMPLATE/joint-review.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/joint-review.md b/.github/ISSUE_TEMPLATE/joint-review.md index 33e49e268..0528092aa 100644 --- a/.github/ISSUE_TEMPLATE/joint-review.md +++ b/.github/ISSUE_TEMPLATE/joint-review.md @@ -23,10 +23,10 @@ Security Provider: yes/no (e.g. Is the primary function of the project to suppor - [ ] Project security lead - [ ] Lead security reviewer - [ ] 1 or more additional reviewer(s) - - [ ] Every reviewer has read [security reviewer guidelines](/community/assessments/guide/security-reviewer.md) and stated declaration of conflict + - [ ] Every reviewer has read [security reviewer guidelines](/community/assessments/guide/joint-assessment.md) and stated declaration of conflict - [ ] Sign off by facilitator on reviewer conflicts - [ ] Create slack channel (e.g. #sec-assess-projectname) -- [ ] Project lead provides draft document - see [outline](/community/assessments/guide/joint-review.md) +- [ ] Project lead provides draft document - see [outline](/community/assessments/guide/joint-assessment.md) - [ ] "Naive question phase" Lead Security Reviewer asks clarifying questions - [ ] Assign issue to security reviewers - [ ] Initial review From 8db0a2d95b6ea2e2066bb17e5056eec7c17b1e08 Mon Sep 17 00:00:00 2001 From: Riaan Kleinhans <61125752+riaankleinhans@users.noreply.github.com> Date: Wed, 31 Jul 2024 17:05:42 -0400 Subject: [PATCH 5/7] Update TAG Security Documents: README and Charter (#1316) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * update tag documents Signed-off-by: riaan kleinhans md lint Signed-off-by: riaan kleinhans rename file Signed-off-by: riaan kleinhans lint fix Signed-off-by: riaan kleinhans spell file Signed-off-by: riaan kleinhans spell Signed-off-by: riaan kleinhans spell Signed-off-by: riaan kleinhans spell Signed-off-by: riaan kleinhans * Update README.md Signed-off-by: Eddie Knight * Update tag-emeritus-leaders.md Signed-off-by: Eddie Knight * Update tag-emeritus-leaders.md Signed-off-by: Eddie Knight * Update README.md Signed-off-by: Eddie Knight * lint error Signed-off-by: riaan kleinhans * lint Signed-off-by: riaan kleinhans * lint Signed-off-by: riaan kleinhans * Update README.md Co-authored-by: Andrés Vega Signed-off-by: Riaan Kleinhans <61125752+riaankleinhans@users.noreply.github.com> * nits Signed-off-by: riaan kleinhans * nits Signed-off-by: riaan kleinhans * nit Signed-off-by: riaan kleinhans --------- Signed-off-by: riaan kleinhans Signed-off-by: Eddie Knight Signed-off-by: Riaan Kleinhans <61125752+riaankleinhans@users.noreply.github.com> Co-authored-by: riaan kleinhans Co-authored-by: Eddie Knight Co-authored-by: Andrés Vega Co-authored-by: Eddie Knight --- README.md | 40 ++----- community/assets/tag-emeritus-leaders.md | 17 +++ governance/README.md | 2 +- governance/charter.md | 141 ----------------------- 4 files changed, 26 insertions(+), 174 deletions(-) create mode 100644 community/assets/tag-emeritus-leaders.md delete mode 100644 governance/charter.md diff --git a/README.md b/README.md index 83d4bd165..94e4ddb32 100644 --- a/README.md +++ b/README.md @@ -74,36 +74,13 @@ Explore groups affiliated with or relevant to Security TAG [here](governance/rel -### Security TAG Chairs - -| Name | Organization | Term | Handle | -|-----------------------|------------------------|---------------------|-----------| -| Pushkar Joglekar | Independent | June, 2023 - June, 2025 | @PushkarJ | -| Marina Moore | Independent | October, 2023 - October, 2025 | @mnm678 | -| Eddie Knight | Sonatype | May, 2024 - May, 2026 | @eddie-knight | - -### Tech Leads - -| Name | Organization | Handle | -|-----------------------|------------------------|---------------------| -| Justin Cappos | New York University | @JustinCappos | -| Ash Narkar | Styra | @ashutosh-narkar | -| Andrés Vega | M42 | @anvega | -| Ragashree Shekar | Independent | @ragashreeshekar | -| Michael Lieberman | Kusari | @mlieberman85 | -| John Kjell | TestifySec | @jkjell | - -### Security TAG Chair Emeriti - -| Name | Organization | Term | Handle | -|-----------------------|------------------------|---------------------|-----------| -| Dan Shaw | PayPal | June, 2019 - September, 2020 | @dshaw | -| Sarah Allen | | June, 2019 - June, 2021 | @ultrasaurus | -| Jeyappragash JJ | Tetrate.io | June, 2019 - June, 2021 | @pragashj | -| Emily Fox | Apple | September, 2020 - February, 2022 | @TheFoxAtWork | -| Brandon Lum | Google | June, 2021 - June, 2023 | @lumjjb | -| Aradhana Chetal | TIAA | June, 2021 - September, 2023 | @achetal01 | -| Andrew Martin | ControlPlane | March, 2022 - March, 2024 | @sublimino| +## Leadership + +Details about the TAG Chairs, Tech Leads, and TOC Liaisons can be found on the [CNCF Technical Advisory Groups (TAGs) information page](https://github.com/cncf/toc/blob/main/tags/cncf-tags.md) + +## TAG Emeritus Leaders + +Thank you to all the [tag emeritus leaders](/community/assets/tag-emeritus-leaders.md) for your contributions to the success of this community. ### Working Groups @@ -129,5 +106,4 @@ For [CNCF project proposal process](https://github.com/cncf/toc/blob/main/proces create a new [security review issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name) with a -[self-assessment](/community/assessments/guide/self-assessment.md) -. +[self-assessment](/community/assessments/guide/self-assessment.md). diff --git a/community/assets/tag-emeritus-leaders.md b/community/assets/tag-emeritus-leaders.md new file mode 100644 index 000000000..84cf3bc8f --- /dev/null +++ b/community/assets/tag-emeritus-leaders.md @@ -0,0 +1,17 @@ +# TAG Security Chair Emeriti + +A big thank you to all the [tag emeritus leaders](/tag-emeritus-leaders.md) of this TAG! Your hard work and dedication have helped to make this project a success. Your valuable contributions have enabled us to develop a strong contributor strategy and build a thriving open-source community. Thank you for all that you have done! + + + +| Name | Organization | Term | Handle | +|-----------------------|------------------------|---------------------|-----------| +| Dan Shaw | PayPal | June, 2019 - September, 2020 | @dshaw | +| Sarah Allen | | June, 2019 - June, 2021 | @ultrasaurus | +| Jeyappragash JJ | Tetrate.io | June, 2019 - June, 2021 | @pragashj | +| Emily Fox | Apple | September, 2020 - February, 2022 | @TheFoxAtWork | +| Brandon Lum | Google | June, 2021 - June, 2023 | @lumjjb | +| Aradhana Chetal | TIAA | June, 2021 - September, 2023 | @achetal01 | +| Andrew Martin | ControlPlane | March, 2022 - March, 2024 | @sublimino| + + diff --git a/governance/README.md b/governance/README.md index 0e2159d00..6ca5f5db6 100644 --- a/governance/README.md +++ b/governance/README.md @@ -3,7 +3,7 @@ Security TAG is a [CNCF Technical Advisory Group](https://github.com/cncf/toc/tree/main/tags). -* [Charter](charter.md) - mission and scope +* [Charter](https://github.com/cncf/toc/tree/main/tags/tag-charters/security-charter.md) - mission and scope * [Roles](roles.md) - the work of the group is facilitated by Chairs, Technical Leads, and active group members * [Process](process.md) - how projects are proposed and work is tracked diff --git a/governance/charter.md b/governance/charter.md deleted file mode 100644 index 72238b5e5..000000000 --- a/governance/charter.md +++ /dev/null @@ -1,141 +0,0 @@ -# Security TAG Charter - -This charter describes operations as a [CNCF TAG](https://github.com/cncf/toc/tree/main/tags). -The [Focus](#focus) section below describes what is in and out of scope, -and [Governance](#governance) section describes how our operations are consistent -with CNCF policies with links to more detailed documents. - -**Mission:** to reduce risk that cloud native -applications expose end user data or allow other unauthorized access. - -## Motivation - -Security has been an area in which open source can flourish and sometimes -has done so; however, with cloud native platforms and applications, security -has received less attention than other areas of the cloud native landscape. - -This means that there is less visibility about the internals of security -projects, and fewer projects being deeply integrated into cloud native tooling. -While there are many open source security projects, there are fewer security -experts focused on the cloud native ecosystem. This has contributed to a culture -where people feel they cannot understand how to securely set up and operate -cloud native systems, due to obscurity and uncertainty. Cloud native principles -have encouraged the development of tools that help manage fast changing -environments, and which have the promise of both simplifying and improving -security. - -Making security more open and understandable is an essential part of this -change. Talking to customers, security is the most important and least -understood part of the cloud native transition. Security is not an easy field, -and it is difficult to measure and value the inputs precisely, which can also -cause issues with evaluation of security software and designs. - -Distributed deployments across heterogeneous infrastructure are increasingly -common for cloud native applications. -Without common ways to programmatically ensure consistent policy, -it is increasingly difficult to evaluate system architecture security at scale. -Emerging common architectural patterns offer the opportunity -improve overall security in cloud native systems. - -## Focus - -In addition to the [CNCF security-related projects](https://landscape.cncf.io/?group=projects-and-products&view-mode=grid&tag=security), there -are three key focus areas: - -* Protection of heterogeneous, distributed and fast changing systems, while -providing needed access -* Common understanding and common tooling to help developers meet security -requirements -* Common tooling for audit and reasoning about system properties. - -### In scope - -Terminology note: Security TAG uses the term "end user" to describe the humans -who use cloud native applications, whereas CNCF refers to companies that operate -cloud native systems as CNCF End Users. In the context of security, we often -need to discuss how a particular control affects the people who use the software -deployed by a company or organization. - -When we use the word "security" within this group, it is defined to be inclusive -of concerns that affect the integrity of the a cloud native -system or the privacy of its users, specifically how to enable secure -access, policy control and safety for operators, administrators, -developers, and end-users across the cloud native ecosystem. - -Security TAG will consider [proposals](process.md) from its members or delegated -tasks from the CNCF TOC that are consistent with the mission, including -the following activities: - -* Publish educational resources on cloud native security - * Videos and/or slides from invited presentations by security providers and - use cases - * Answer the following questions (referring to already existing resources - where possible): - * What is different about cloud security? (including hybrid and multi-cloud) - * What are effective practices for implementing policy controls? - * How can we test, validate, explain, audit our systems? - * What additional measures are needed, specific to cloud, in highly - regulated environments? - * Personas and use cases - * Common vocabulary to talk about and understand cloud native security - * CNCF project ecosystem & landscape - * Define security scenarios (e.g. network configuration, application security, - service orchestration) - * Block architecture(s) for secure access - * Highlight trade-offs (e.g. Expressibility vs Explainability) - * Best practices and anti-patterns (potentially highlighting where there is - disagreement on these) -* Security assessments of specific proposals or projects -* Identify projects for consideration for CNCF -* Cross-pollinate knowledge by participating and inviting people from other projects and TAGs to share security practices -* Integrate relevant external standards, such as from OpenSSF or NIST, as part of educational resources and/or TAG processes - -Given that the group is comprised of volunteers, specific requests from the TOC -may be queued according to the bandwidth of the group. The co-chairs will -facilitate prioritization under the guidance of the Security TAG TOC liaison. - -### Out of scope - -* Not a standards body: We won't be creating standards. -* Not an umbrella organization: We interact with other groups for knowledge - sharing, not decision-making. -* Not a compliance body -* Not a certification board for security of individual projects -* We will not - * answer any specific questions regarding the state of security of any project - or product - * consider device security unless there is some impact to cloud systems. - * explore trust and safety concerns that are not specific to cloud - (e.g. fraud detection, user generated content moderation, spam filtering, - phishing, cross-site scripting attacks, SQL injection, etc.) -* We will not ensure the safety of any operational system. -* This is not related to vulnerability detection and handling any specific - security vulnerability or attack. - -## Governance - -Security must be addressed at all levels of the stack and across the whole -ecosystem, so the group seeks to encourage participation and membership across -a wide range of roles, from diverse companies and organizations. - -### Cross-group relationships - -To focus our efforts, we avoid duplication by developing relationships with -other groups that -focus on a particular technology (such as Kubernetes SIGs) or have a broader -mandate (such as government organizations). - -As a guide to visitors, we maintain the list of groups in the TAG -[README](https://github.com/cncf/tag-security#related-groups). - -Co-chairs are responsible to ensure periodic cross-group knowledge sharing, -which is accomplished by cross-group membership, invitation to present at -a TAG meeting and/or offering to present to the related group. - -## Operations - -Security TAG operations are consistent with standard TAG operating guidelines -provided by the CNCF Technical Oversight Committee -[TOC](https://github.com/cncf/toc). - -Full details of process and roles are linked from [governance README](/governance). From 282719f876b235c9dcb80698c3da7a1ab7469c76 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 1 Aug 2024 10:52:06 -0400 Subject: [PATCH 6/7] Add moving levels template (#1331) * Add initial template for projects moving levels Signed-off-by: Marina Moore * Add moving levels template to presentation template Signed-off-by: Marina Moore * Fix linting errors Signed-off-by: Marina Moore * More linting fixes Signed-off-by: Marina Moore --------- Signed-off-by: Marina Moore --- .github/ISSUE_TEMPLATE/presentation.md | 1 + .../moving-levels-review-template.md | 37 +++++++++++++++++++ 2 files changed, 38 insertions(+) create mode 100644 project-resources/moving-levels-review-template.md diff --git a/.github/ISSUE_TEMPLATE/presentation.md b/.github/ISSUE_TEMPLATE/presentation.md index 82695288e..f8dd02d04 100644 --- a/.github/ISSUE_TEMPLATE/presentation.md +++ b/.github/ISSUE_TEMPLATE/presentation.md @@ -20,3 +20,4 @@ TO DO - [ ] TAG Representative - [ ] Schedule date - [ ] By opening this issue, I, (Insert Github Handle/Name) acknowledge that the presentation topic and speaker will follow the [presentation guidelines](../CONTRIBUTING.md#present-to-the-tag) +- [ ] If this is a presentation for a project moving levels, the TAG Representative should complete the [Moving Levels Recommendation](../project-resources/moving-levels-review-template.md) diff --git a/project-resources/moving-levels-review-template.md b/project-resources/moving-levels-review-template.md new file mode 100644 index 000000000..a160e5b7d --- /dev/null +++ b/project-resources/moving-levels-review-template.md @@ -0,0 +1,37 @@ +# Template for TAG recommendation to TOC + +## Project Overview + +### Ecosystem Adoption + +What ecosystem adoption has the project seen? + +### Past TOC Reviews + +How has the project addressed comments from previous reviews (incubation if graduation, sandbox if incubating, etc)? + +## Security Reviews + +### TAG Security Assessments + +Has the project completed a TAG Security Self-Assessment and/or Joint Assessment? If yes, please add a link and discuss how this has impacted their security posture. + +### Security Audit + +Has the project completed an external security audit? If yes, how have they addressed the findings? + +## Best Practices + +### Metrics + +Which security best practices does the project follow (for example CNCF best practices badge, OpenSSF Best Practices, CLO monitor), and how does it rate by these metrics? + +### Static Analysis + +Does the project perform static analysis? + +## Sub-project Considerations + +If the project has sub-projects, how does their security posture compare to the base project? + +## TAG Recommendation to the TOC From b3c06f16941c49b3f9461ec5d70668de1d2052ce Mon Sep 17 00:00:00 2001 From: Chris Abraham Date: Wed, 7 Aug 2024 09:48:11 +0700 Subject: [PATCH 7/7] Add pages for Supply Chain Security Tools Mappings (#1319) * Don't store search increments in the browser history Signed-off-by: Chris Abraham * Add pages for Supply Chain Security Tools Mappings Signed-off-by: Chris Abraham * update copy Signed-off-by: Chris Abraham * fix lint and spelling Signed-off-by: Chris Abraham * Reformat requirements sections Signed-off-by: Chris Abraham * Fill out requirements Signed-off-by: Chris Abraham --------- Signed-off-by: Chris Abraham --- ci/spelling-config.json | 2 + .../supply-chain-security-tools/README.md | 11 + .../securing-artifacts.md | 108 +++++++ .../securing-build-pipelines.md | 272 ++++++++++++++++++ .../securing-deployments.md | 42 +++ .../securing-materials.md | 109 +++++++ .../securing-source-code.md | 156 ++++++++++ website/layouts/_default/search.html | 2 +- 8 files changed, 701 insertions(+), 1 deletion(-) create mode 100644 publications/supply-chain-security-tools/README.md create mode 100644 publications/supply-chain-security-tools/securing-artifacts.md create mode 100644 publications/supply-chain-security-tools/securing-build-pipelines.md create mode 100644 publications/supply-chain-security-tools/securing-deployments.md create mode 100644 publications/supply-chain-security-tools/securing-materials.md create mode 100644 publications/supply-chain-security-tools/securing-source-code.md diff --git a/ci/spelling-config.json b/ci/spelling-config.json index eabc7a458..2d2989db1 100644 --- a/ci/spelling-config.json +++ b/ci/spelling-config.json @@ -60,6 +60,8 @@ "frontmatter", "Gamal", "gconv", + "gitsign", + "gittuf", "GUAC", "helm", "HIPAA", diff --git a/publications/supply-chain-security-tools/README.md b/publications/supply-chain-security-tools/README.md new file mode 100644 index 000000000..1d80eade9 --- /dev/null +++ b/publications/supply-chain-security-tools/README.md @@ -0,0 +1,11 @@ +# Supply Chain Security Tools Mappings + +{{% blocks/lead color="white" align="left" %}} +Find out what tools are used to secure the supply chain. Explore the general requirement categories below. +{{% /blocks/lead %}} + +1. [Securing the Source Code](securing-source-code.md) +2. [Securing Materials](securing-materials.md) +3. [Securing Build Pipelines](securing-build-pipelines.md) +4. [Securing Artifacts](securing-artifacts.md) +5. [Securing Deployments](securing-deployments.md) diff --git a/publications/supply-chain-security-tools/securing-artifacts.md b/publications/supply-chain-security-tools/securing-artifacts.md new file mode 100644 index 000000000..91bbdbf33 --- /dev/null +++ b/publications/supply-chain-security-tools/securing-artifacts.md @@ -0,0 +1,108 @@ +# Securing Artifacts + +{{% blocks/lead color="white" align="left" %}} +Here are the list of requirements for securing artifacts. Each one has a list of tools used to achieve it. +{{% /blocks/lead %}} + +## 1. Sign Every Step in the Build Process + +### Tool capability + +- sign attestations for every step in the build process +- define all expected steps in the build process with identities + +### Tools + +- SLSA (level 1) +- in-toto +- Tekton (chains) + +## 2. Validate the Signatures Generated at Each Step + +### Tool capability + +- verify attestations of every step + +### Tools + +- in-toto +- Kyverno (signatures of output images are verified before running containers) + +## 3. Use TUF/Notary to manage signing of artefacts + +### Tool capability + +- delegate trust for specific artifacts to specific developers +- enable developer signing of metadata +- prevent rollback attacks on developer signatures + +### Tools + +- TUF +- Tekton (chains uses Sigstore) +- Kyverno (Kyverno supports Sigstore) + +## 4. Use a store to manage metadata from in-toto + +### Tool capability + +- store in-toto metadata + +### Tools + +- Sigstore (Rekor?) +- in-toto (integrated with Rekor, Grafeas, Archivist etc.) +- Tekton (chains) + + +## 5. Limit which artefacts any given party is authorized to certify + +### Tool capability + +- specify trusted entities for each artifact in policy +- enforce this limitation + +### Tools + +- in-toto +- TUF +- Kyverno (Kyverno policy on who is trusted for each signature) + + +## 6. Build in a system for rotating and revoking private keys + +### Tool capability + +- change policy to revoke a trusted key +- change policy to rotate a trusted key +- communicate these changes to users + +### Tools + +- Sigstore (Fulcio) +- in-toto (in-toto layouts can rotate and revoke keys for attestations, layout keys are managed separately such as by using TUF) +- TUF +- SPIFFE + +## 7. Use a container registry that supports OCI image-spec images + +### Tool capability + +- follow the OCI spec + +### Tools + +- Sigstore (cosign) +- Tekton (Pipelines and Chains) +- Kyverno (Kyverno works with OCI registries) + +## 8. Encrypt artefacts before distribution & ensure only authorized platforms have decryption capabilities + +### Tool capability + +- create policy for which platforms have decryption capabilities +- enforce this policy + +### Tools + +- _none_ diff --git a/publications/supply-chain-security-tools/securing-build-pipelines.md b/publications/supply-chain-security-tools/securing-build-pipelines.md new file mode 100644 index 000000000..760f9ed05 --- /dev/null +++ b/publications/supply-chain-security-tools/securing-build-pipelines.md @@ -0,0 +1,272 @@ +# Securing Build Pipelines + +{{% blocks/lead color="white" align="left" %}} +Here are the list of requirements for securing build pipelines. Each one has a list of tools used to achieve it. +{{% /blocks/lead %}} + +## 1. Cryptographically guarantee policy adherence + +### Tool capability + +- attest to steps +- verify policy adherence +- define the policy + +### Tools + +- SLSA (level 1) +- in-toto + + +## 2. Validate environments and dependencies before usage + +### Tool capability + +- validate dependencies +- validate environments +- verify signatures on build images + +### Tools + +- in-toto (in-toto can wrap the fetch / bootstrap processes and metadata can be consumed by upper-turtle processes via sublayouts) +- SPIFFE (validates environments) +- Tekton (there is an open TEP to integrate with SPIFFE to validate node/workload) +- Kyverno (If the environment is a container, Kyverno can verify the policy (allowed source, signer)) + +## 3. Validate runtime security of build workers + +### Tool capability + +- monitor runtime processes +- attest to runtime operations +- verify runtime attestations +- trusted execution environment + +### Tools + +- in-toto (runtime trace attestations) + +## 4. Validate Build artifacts through verifiably reproducible builds + +### Tool capability + +- make reproducible build +- re-build images in isolated environments (security enclaves/trust boundaries) +- validate builds from multiple sources + +### Tools + +- in-toto +- apko + +## 5. Lock and Verify External Requirements From The Build Process + +### Tool capability + +- lock and record external requirements +- verify external requirements + +### Tools + +- apko + +## 6. Find and Eliminate Sources Of Non-Determinism + +### Tool capability + +- make diffs of builds + +### Tools + +- apko + +## 7. Record The Build Environment + +### Tool capability + +- record the build environment + +### Tools + +- SLSA (level 3) +- in-toto (in-toto provides the formats, it's unopinionated about what's recorded) +- apko +- Tekton (Chains) + +## 8. Automate Creation Of The Build Environment + +### Tool capability + +- environment creation automation + +### Tools + +- apko +- Tekton (Pipelines) + +## 9. Distribute Builds Across Different Infrastructure + +### Tool capability + +- define multiple infrastructure setups +- run builds in multiple environments + +### Tools + +- Tekton (Pipelines) + +## 10. Build and related continuous integration/continuous delivery steps should all be automated through a pipeline defined as code + +### Tool capability + +- define pipeline in code +- run pipeline as code + +### Tools + +- SLSA (level 1) +- apko +- Tekton (Pipelines) + +## 11. Standardize pipelines across projects + +### Tool capability + +- _none_ + +### Tools + +- Tekton (Pipelines) + +## 12. Provision a secured orchestration platform to host software factory + +### Tool capability + +- perform secure orchestration + +### Tools + +- Tekton (Pipelines) + +## 13. Build Workers Should be Single Use + +### Tool capability + +- single-use containerized builders +- verify that builders are single use +- attest to build identity + +### Tools + +- SLSA (level 3) +- in-toto (can be validated via runtime trace attestations) +- Tekton (Pipelines) + +## 14. Ensure Software Factory has minimal network connectivity. + +### Tool capability + +- check for and monitor network connections + +### Tools + +- SLSA (level 3) +- in-toto (can be validated via runtime trace attestations) + +## 15. Segregate the Duties of Each Build Worker + +### Tool capability + +- define scope of each build worker +- attest to which build worker performs each action +- verify that build workers follow the policy + +### Tools + +- in-toto +- Tekton (Pipelines) + +## 15. Pass in Build Worker Environment and Commands + +### Tool capability + +- provision build workers with environment and commands within a hermetic build environment + +### Tools + +- in-toto (can be validated via runtime trace attestations) +- Tekton (Pipelines) + +## 16. Write Output to a Separate Secured Storage Repo + +### Tool capability + +- secured storage repo + +### Tools + +- Sigstore (Rekor) +- in-toto (depending on where you put the in-toto metadata) + +## 17. Only allow pipeline modifications through "pipeline as code" + +### Tool capability + +- attest to pipeline state and modifications +- verify that pipeline modifications are made through pipeline as code +- ensure pipeline goes through source control + +### Tools + +- SLSA (level 3) +- Tekton (Pipelines) + +## 18. Define user roles + +### Tool capability + +- define user roles +- attest to role for each action +- enforce user roles + +### Tools + +- in-toto + +## 19. Follow established practices for establishing a root of trust from an offline source + +### Tool capability + +- securely distribute root of trust +- chain from existing trusted root + +### Tools + +- TUF + +## 20. Use short-lived Workload Certificates + +### Tool capability + +- create short-lived certificates +- verify short-lived certificates using their validity period +- verify that workload certificates are short-lived + +### Tools + +- in-toto (integrates with SPIFFE/SPIRE) +- SPIFFE +- Tekton (TEP to integrate with SPIRE) + +## 21. Deploy monitoring tools to software factory to detect malicious behaviour + +### Tool capability + +- runtime monitoring +- analysis of built artifacts + +### Tools + +- in-toto (runtime trace attestations generated using tools like tetragon) +- SPIFFE +- Tekton (TEP to integrate with SPIRE) diff --git a/publications/supply-chain-security-tools/securing-deployments.md b/publications/supply-chain-security-tools/securing-deployments.md new file mode 100644 index 000000000..f37396ebc --- /dev/null +++ b/publications/supply-chain-security-tools/securing-deployments.md @@ -0,0 +1,42 @@ +# Securing Deployments + +{{% blocks/lead color="white" align="left" %}} +Here are the list of requirements for securing deployments. Each one has a list of tools used to achieve it. +{{% /blocks/lead %}} + +## 1. Ensure clients can perform Verification of Artefacts and associated metadata + +### Tool capability + +- perform client verification + +### Tools + +- Sigstore (cosign) +- in-toto (in-toto implementations support verification of metadata against layouts) +- TUF +- Tekton (chains with sigstore) +- Kyverno (Kyverno policies validate artifacts and metadata) + + +## 2. Ensure clients can verify the "freshness" of files + +### Tool capability + +- verify freshness of files + +### Tools + +- Sigstore (Rekor) +- TUF + +## 3. Use The Update Framework + +### Tool capability + +- support TUF metadata creation +- support TUF metadata verification + +### Tools + +- TUF diff --git a/publications/supply-chain-security-tools/securing-materials.md b/publications/supply-chain-security-tools/securing-materials.md new file mode 100644 index 000000000..78b8e2a37 --- /dev/null +++ b/publications/supply-chain-security-tools/securing-materials.md @@ -0,0 +1,109 @@ +# Securing Materials + +{{% blocks/lead color="white" align="left" %}} +Here are the list of requirements for securing materials. Each one has a list of tools used to achieve it. +{{% /blocks/lead %}} + +## 1. Verify third party artefacts and open source libraries + +### Tool capability + +- attest to review +- verify review attestations + +### Tools + +- in-toto (can be validated via alpha-omega attestations, review attestations) + + +## 2. Require SBOM from third party supplier + +### Tool capability + +- generate accurate SBOM +- verify SBOM existence +- verify SBOM accuracy + +### Tools + +- _none_ + +## 3. Track dependencies between open source components + +### Tool capability + +- create accurate SBOM +- update SBOM + +### Tools + +- _none_ + +## 4. Build libraries based upon source code + +### Tool capability + +- attest to build +- verify attestation of build +- maintain list of trusted sources for built software +- attestation from third-party builder/distributor +- publish hashes for pre-built software + +### Tools + +- in-toto +- apko + +## 5. Define and prioritize trusted package managers and repositories + +### Tool capability + +- define trusted/prioritized repositories +- enforce the priority + +### Tools + +- TUF + +## 6. Generate an immutable SBOM of the code + +### Tool capability + +- generate an accurate SBOM (signed) + +### Tools + +- in-toto (SBOM attestations) +- apko + +## 7. Scan software for vulnerabilities + +### Tool capability + +- scan the software + +### Tools + +- in-toto + +## 8. Scan software for license implications + +### Tool capability + +- scan the software + +### Tools + +- _none_ + +## 9. Run software composition analysis on ingested software + +### Tool capability + +- run software composition analysis +- ingest an SBOM +- verify an SBOM's claims + +### Tools + +- _none_ diff --git a/publications/supply-chain-security-tools/securing-source-code.md b/publications/supply-chain-security-tools/securing-source-code.md new file mode 100644 index 000000000..7476b7305 --- /dev/null +++ b/publications/supply-chain-security-tools/securing-source-code.md @@ -0,0 +1,156 @@ +# Securing the Source Code + +{{% blocks/lead color="white" align="left" %}} +Here are the list of requirements for securing the source code, which is a subcategory of the overall requirements for supply chain security. For each requirement is a list of tools used to meet that requirement. +{{% /blocks/lead %}} + +## 1. Require signed commits + +### Tool capability + +- sign commits +- verify signed commits + +### Tools + +- Sigstore (gitsign) +- gittuf +- GUAC + +## 2. Enforce full attestation and verification for protected branches + +### Tool capability + +- monitor protected branches + +### Tools + +- gittuf + +## 3. Prevent committing secrets to the source code repository + +### Tool capability + +- check commits +- verify that no secrets are in the repository + +### Tools + +- _none_ + +## 4. Define individuals/teams that are responsible for code in a repository and associated coding conventions + +### Tool capability + +- verifying coding conventions + +### Tools + +- GitHub +- gittuf +- GUAC + +## 5. Automate software security scanning and testing + +### Tool capability + +- scan software +- perform tests +- automation at build time +- automation at production time +- determine what to do with scan results + +### Tools + +- in-toto (test result attestations) + +## 6. Establish and adhere to contribution policies + +### Tool capability + +- check for contribution guidelines +- DCO + +### Tools + +- GitHub + +## 7. Define roles aligned to functional responsibilities + +### Tool capability + +- none + +### Tools + +- GitHub +- gittuf + +## 8. Enforce an independent four-eyes principle + +### Tool capability + +- require review before merge +- attest to a review +- verify attestation of review + +### Tools + +- SLSA (level 4) +- in-toto (threshold of human review attestations) +- GitHub + + +## 9. Use branch protection rules + +### Tool capability + +- verify branch protection is turned on over time + +### Tools + +- GitHub +- gittuf + +## 10. Enforce MFA for accessing source code repositories + +### Tool capability + +- enable MFA +- verify MFA is enabled for all contributors + +### Tools + +- GitHub + +## 11. Use SSH keys to provide developers access to source code repositories + +### Tool capability + +- enforce that ssh keys are used (and disable https) + +### Tools + +- GitHub + +## 12. Have a Key Rotation Policy + +### Tool capability + +- key expiration +- key distribution/PKI for ssh + +### Tools + +- gittuf + +## 13. Use short-lived/ephemeral credentials for machine/service access + +### Tool capability + +- require short-lived credentials + +### Tools + +- SPIFFE (maybe, spiffe does short-lived credentials, but not sure if anyone is using this for source code repos) + diff --git a/website/layouts/_default/search.html b/website/layouts/_default/search.html index bbd1ecf8a..c778147c4 100644 --- a/website/layouts/_default/search.html +++ b/website/layouts/_default/search.html @@ -55,7 +55,7 @@

{{ .Title }}

var newUrl = baseUrl + "?" + urlParams.toString(); // Update the browser history (optional) - window.history.pushState({}, null, newUrl); + history.replaceState(null, '', newUrl); }