diff --git a/.github/ISSUE_TEMPLATE/blog-submission.md b/.github/ISSUE_TEMPLATE/blog-submission.md
new file mode 100644
index 000000000..6fa402044
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/blog-submission.md
@@ -0,0 +1,18 @@
+---
+name: Blog Submission
+about: Propose and author a blog article for publication on the tag-security.cncf.io website
+title: "[Blog] some descriptive title"
+labels: "blog, triage-required"
+assignees: ''
+
+---
+
+Description: What's your idea?
+
+Impact: What is the purpose of this blog post? 
+
+Sponsor: If applicable mention a related issue or the related working group this blog originates from.
+
+Additional info:
+- Reference to supporting material
+- Links to related site
diff --git a/.github/ISSUE_TEMPLATE/joint-review.md b/.github/ISSUE_TEMPLATE/joint-review.md
index c5cfc9dec..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](https://github.com/cncf/tag-security/blob/main/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](https://github.com/cncf/tag-security/blob/main/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
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/.github/auto_request_review.yml b/.github/auto_request_review.yml
index de75447b3..a4f9d865c 100644
--- a/.github/auto_request_review.yml
+++ b/.github/auto_request_review.yml
@@ -19,7 +19,6 @@ reviewers:
       - JustinCappos
       - achetal01
       - ashutosh-narkar
-      - anvega
       - PushkarJ
       - mnm678
       - mlieberman85
diff --git a/.github/workflows/sig-sec-check.yml b/.github/workflows/sig-sec-check.yml
index 415194275..c0cede4b2 100644
--- a/.github/workflows/sig-sec-check.yml
+++ b/.github/workflows/sig-sec-check.yml
@@ -11,27 +11,27 @@ jobs:
   Setup:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
       - name: Setup
         run: make setup
   Lint:
     runs-on: ubuntu-latest
     needs: Setup
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
       - name: Lint
         run: make lint
   Spelling:
     runs-on: ubuntu-latest
     needs: Setup
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
       - name: Spelling
         run: make spelling
   Links:
     runs-on: ubuntu-latest
     needs: Setup
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
       - name: Links
         run: make links
diff --git a/CODE-OF-CONDUCT.md b/CODE-OF-CONDUCT.md
index 40147b635..627e1918d 100644
--- a/CODE-OF-CONDUCT.md
+++ b/CODE-OF-CONDUCT.md
@@ -120,5 +120,5 @@ The above guidelines are inspired by and borrowed from other communities:
 
 [cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md  
 [charter]: https://github.com/cncf/tag-security/blob/main/governance/charter.md
-[review-outcome]: https://github.com/cncf/tag-security/tree/main/assessments#outcome
+[review-outcome]: /community/assessments#outcome
 [cncf-toc]: https://www.cncf.io/people/technical-oversight-committee/
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c78ae3ed7..940033a66 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -197,7 +197,7 @@ Here are some additional sources for good content guidelines:
 [CODE-OF-CONDUCT.md]: CODE-OF-CONDUCT.md
 [help is needed]: https://github.com/cncf/tag-security/labels/help%20wanted
 [communication channels]: README.md#Communications
-[security reviews]: ./assessments/README.md
+[security reviews]: /community/assessments/README.md
 [CNCF Slack guidelines]: https://github.com/cncf/foundation/blob/main/slack-guidelines.md
 [code of conduct]: ./CODE-OF-CONDUCT.md
 [CNCF Style Guide]: https://github.com/cncf/foundation/blob/main/style-guide.md
diff --git a/LICENSE-code b/LICENSE-code
deleted file mode 100644
index 261eeb9e9..000000000
--- a/LICENSE-code
+++ /dev/null
@@ -1,201 +0,0 @@
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright [yyyy] [name of copyright owner]
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.
diff --git a/LICENSE-document b/LICENSE-document
deleted file mode 100644
index 2802779ed..000000000
--- a/LICENSE-document
+++ /dev/null
@@ -1,395 +0,0 @@
-Attribution 4.0 International
-
-=======================================================================
-
-Creative Commons Corporation ("Creative Commons") is not a law firm and
-does not provide legal services or legal advice. Distribution of
-Creative Commons public licenses does not create a lawyer-client or
-other relationship. Creative Commons makes its licenses and related
-information available on an "as-is" basis. Creative Commons gives no
-warranties regarding its licenses, any material licensed under their
-terms and conditions, or any related information. Creative Commons
-disclaims all liability for damages resulting from their use to the
-fullest extent possible.
-
-Using Creative Commons Public Licenses
-
-Creative Commons public licenses provide a standard set of terms and
-conditions that creators and other rights holders may use to share
-original works of authorship and other material subject to copyright
-and certain other rights specified in the public license below. The
-following considerations are for informational purposes only, are not
-exhaustive, and do not form part of our licenses.
-
-     Considerations for licensors: Our public licenses are
-     intended for use by those authorized to give the public
-     permission to use material in ways otherwise restricted by
-     copyright and certain other rights. Our licenses are
-     irrevocable. Licensors should read and understand the terms
-     and conditions of the license they choose before applying it.
-     Licensors should also secure all rights necessary before
-     applying our licenses so that the public can reuse the
-     material as expected. Licensors should clearly mark any
-     material not subject to the license. This includes other CC-
-     licensed material, or material used under an exception or
-     limitation to copyright. More considerations for licensors:
-	wiki.creativecommons.org/Considerations_for_licensors
-
-     Considerations for the public: By using one of our public
-     licenses, a licensor grants the public permission to use the
-     licensed material under specified terms and conditions. If
-     the licensor's permission is not necessary for any reason--for
-     example, because of any applicable exception or limitation to
-     copyright--then that use is not regulated by the license. Our
-     licenses grant only permissions under copyright and certain
-     other rights that a licensor has authority to grant. Use of
-     the licensed material may still be restricted for other
-     reasons, including because others have copyright or other
-     rights in the material. A licensor may make special requests,
-     such as asking that all changes be marked or described.
-     Although not required by our licenses, you are encouraged to
-     respect those requests where reasonable. More_considerations
-     for the public: 
-	wiki.creativecommons.org/Considerations_for_licensees
-
-=======================================================================
-
-Creative Commons Attribution 4.0 International Public License
-
-By exercising the Licensed Rights (defined below), You accept and agree
-to be bound by the terms and conditions of this Creative Commons
-Attribution 4.0 International Public License ("Public License"). To the
-extent this Public License may be interpreted as a contract, You are
-granted the Licensed Rights in consideration of Your acceptance of
-these terms and conditions, and the Licensor grants You such rights in
-consideration of benefits the Licensor receives from making the
-Licensed Material available under these terms and conditions.
-
-
-Section 1 -- Definitions.
-
-  a. Adapted Material means material subject to Copyright and Similar
-     Rights that is derived from or based upon the Licensed Material
-     and in which the Licensed Material is translated, altered,
-     arranged, transformed, or otherwise modified in a manner requiring
-     permission under the Copyright and Similar Rights held by the
-     Licensor. For purposes of this Public License, where the Licensed
-     Material is a musical work, performance, or sound recording,
-     Adapted Material is always produced where the Licensed Material is
-     synched in timed relation with a moving image.
-
-  b. Adapter's License means the license You apply to Your Copyright
-     and Similar Rights in Your contributions to Adapted Material in
-     accordance with the terms and conditions of this Public License.
-
-  c. Copyright and Similar Rights means copyright and/or similar rights
-     closely related to copyright including, without limitation,
-     performance, broadcast, sound recording, and Sui Generis Database
-     Rights, without regard to how the rights are labeled or
-     categorized. For purposes of this Public License, the rights
-     specified in Section 2(b)(1)-(2) are not Copyright and Similar
-     Rights.
-
-  d. Effective Technological Measures means those measures that, in the
-     absence of proper authority, may not be circumvented under laws
-     fulfilling obligations under Article 11 of the WIPO Copyright
-     Treaty adopted on December 20, 1996, and/or similar international
-     agreements.
-
-  e. Exceptions and Limitations means fair use, fair dealing, and/or
-     any other exception or limitation to Copyright and Similar Rights
-     that applies to Your use of the Licensed Material.
-
-  f. Licensed Material means the artistic or literary work, database,
-     or other material to which the Licensor applied this Public
-     License.
-
-  g. Licensed Rights means the rights granted to You subject to the
-     terms and conditions of this Public License, which are limited to
-     all Copyright and Similar Rights that apply to Your use of the
-     Licensed Material and that the Licensor has authority to license.
-
-  h. Licensor means the individual(s) or entity(ies) granting rights
-     under this Public License.
-
-  i. Share means to provide material to the public by any means or
-     process that requires permission under the Licensed Rights, such
-     as reproduction, public display, public performance, distribution,
-     dissemination, communication, or importation, and to make material
-     available to the public including in ways that members of the
-     public may access the material from a place and at a time
-     individually chosen by them.
-
-  j. Sui Generis Database Rights means rights other than copyright
-     resulting from Directive 96/9/EC of the European Parliament and of
-     the Council of 11 March 1996 on the legal protection of databases,
-     as amended and/or succeeded, as well as other essentially
-     equivalent rights anywhere in the world.
-
-  k. You means the individual or entity exercising the Licensed Rights
-     under this Public License. Your has a corresponding meaning.
-
-
-Section 2 -- Scope.
-
-  a. License grant.
-
-       1. Subject to the terms and conditions of this Public License,
-          the Licensor hereby grants You a worldwide, royalty-free,
-          non-sublicensable, non-exclusive, irrevocable license to
-          exercise the Licensed Rights in the Licensed Material to:
-
-            a. reproduce and Share the Licensed Material, in whole or
-               in part; and
-
-            b. produce, reproduce, and Share Adapted Material.
-
-       2. Exceptions and Limitations. For the avoidance of doubt, where
-          Exceptions and Limitations apply to Your use, this Public
-          License does not apply, and You do not need to comply with
-          its terms and conditions.
-
-       3. Term. The term of this Public License is specified in Section
-          6(a).
-
-       4. Media and formats; technical modifications allowed. The
-          Licensor authorizes You to exercise the Licensed Rights in
-          all media and formats whether now known or hereafter created,
-          and to make technical modifications necessary to do so. The
-          Licensor waives and/or agrees not to assert any right or
-          authority to forbid You from making technical modifications
-          necessary to exercise the Licensed Rights, including
-          technical modifications necessary to circumvent Effective
-          Technological Measures. For purposes of this Public License,
-          simply making modifications authorized by this Section 2(a)
-          (4) never produces Adapted Material.
-
-       5. Downstream recipients.
-
-            a. Offer from the Licensor -- Licensed Material. Every
-               recipient of the Licensed Material automatically
-               receives an offer from the Licensor to exercise the
-               Licensed Rights under the terms and conditions of this
-               Public License.
-
-            b. No downstream restrictions. You may not offer or impose
-               any additional or different terms or conditions on, or
-               apply any Effective Technological Measures to, the
-               Licensed Material if doing so restricts exercise of the
-               Licensed Rights by any recipient of the Licensed
-               Material.
-
-       6. No endorsement. Nothing in this Public License constitutes or
-          may be construed as permission to assert or imply that You
-          are, or that Your use of the Licensed Material is, connected
-          with, or sponsored, endorsed, or granted official status by,
-          the Licensor or others designated to receive attribution as
-          provided in Section 3(a)(1)(A)(i).
-
-  b. Other rights.
-
-       1. Moral rights, such as the right of integrity, are not
-          licensed under this Public License, nor are publicity,
-          privacy, and/or other similar personality rights; however, to
-          the extent possible, the Licensor waives and/or agrees not to
-          assert any such rights held by the Licensor to the limited
-          extent necessary to allow You to exercise the Licensed
-          Rights, but not otherwise.
-
-       2. Patent and trademark rights are not licensed under this
-          Public License.
-
-       3. To the extent possible, the Licensor waives any right to
-          collect royalties from You for the exercise of the Licensed
-          Rights, whether directly or through a collecting society
-          under any voluntary or waivable statutory or compulsory
-          licensing scheme. In all other cases the Licensor expressly
-          reserves any right to collect such royalties.
-
-
-Section 3 -- License Conditions.
-
-Your exercise of the Licensed Rights is expressly made subject to the
-following conditions.
-
-  a. Attribution.
-
-       1. If You Share the Licensed Material (including in modified
-          form), You must:
-
-            a. retain the following if it is supplied by the Licensor
-               with the Licensed Material:
-
-                 i. identification of the creator(s) of the Licensed
-                    Material and any others designated to receive
-                    attribution, in any reasonable manner requested by
-                    the Licensor (including by pseudonym if
-                    designated);
-
-                ii. a copyright notice;
-
-               iii. a notice that refers to this Public License;
-
-                iv. a notice that refers to the disclaimer of
-                    warranties;
-
-                 v. a URI or hyperlink to the Licensed Material to the
-                    extent reasonably practicable;
-
-            b. indicate if You modified the Licensed Material and
-               retain an indication of any previous modifications; and
-
-            c. indicate the Licensed Material is licensed under this
-               Public License, and include the text of, or the URI or
-               hyperlink to, this Public License.
-
-       2. You may satisfy the conditions in Section 3(a)(1) in any
-          reasonable manner based on the medium, means, and context in
-          which You Share the Licensed Material. For example, it may be
-          reasonable to satisfy the conditions by providing a URI or
-          hyperlink to a resource that includes the required
-          information.
-
-       3. If requested by the Licensor, You must remove any of the
-          information required by Section 3(a)(1)(A) to the extent
-          reasonably practicable.
-
-       4. If You Share Adapted Material You produce, the Adapter's
-          License You apply must not prevent recipients of the Adapted
-          Material from complying with this Public License.
-
-
-Section 4 -- Sui Generis Database Rights.
-
-Where the Licensed Rights include Sui Generis Database Rights that
-apply to Your use of the Licensed Material:
-
-  a. for the avoidance of doubt, Section 2(a)(1) grants You the right
-     to extract, reuse, reproduce, and Share all or a substantial
-     portion of the contents of the database;
-
-  b. if You include all or a substantial portion of the database
-     contents in a database in which You have Sui Generis Database
-     Rights, then the database in which You have Sui Generis Database
-     Rights (but not its individual contents) is Adapted Material; and
-
-  c. You must comply with the conditions in Section 3(a) if You Share
-     all or a substantial portion of the contents of the database.
-
-For the avoidance of doubt, this Section 4 supplements and does not
-replace Your obligations under this Public License where the Licensed
-Rights include other Copyright and Similar Rights.
-
-
-Section 5 -- Disclaimer of Warranties and Limitation of Liability.
-
-  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
-     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
-     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
-     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
-     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
-     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
-     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
-     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
-     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
-     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
-
-  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
-     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
-     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
-     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
-     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
-     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
-     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
-     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
-     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
-
-  c. The disclaimer of warranties and limitation of liability provided
-     above shall be interpreted in a manner that, to the extent
-     possible, most closely approximates an absolute disclaimer and
-     waiver of all liability.
-
-
-Section 6 -- Term and Termination.
-
-  a. This Public License applies for the term of the Copyright and
-     Similar Rights licensed here. However, if You fail to comply with
-     this Public License, then Your rights under this Public License
-     terminate automatically.
-
-  b. Where Your right to use the Licensed Material has terminated under
-     Section 6(a), it reinstates:
-
-       1. automatically as of the date the violation is cured, provided
-          it is cured within 30 days of Your discovery of the
-          violation; or
-
-       2. upon express reinstatement by the Licensor.
-
-     For the avoidance of doubt, this Section 6(b) does not affect any
-     right the Licensor may have to seek remedies for Your violations
-     of this Public License.
-
-  c. For the avoidance of doubt, the Licensor may also offer the
-     Licensed Material under separate terms or conditions or stop
-     distributing the Licensed Material at any time; however, doing so
-     will not terminate this Public License.
-
-  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
-     License.
-
-
-Section 7 -- Other Terms and Conditions.
-
-  a. The Licensor shall not be bound by any additional or different
-     terms or conditions communicated by You unless expressly agreed.
-
-  b. Any arrangements, understandings, or agreements regarding the
-     Licensed Material not stated herein are separate from and
-     independent of the terms and conditions of this Public License.
-
-
-Section 8 -- Interpretation.
-
-  a. For the avoidance of doubt, this Public License does not, and
-     shall not be interpreted to, reduce, limit, restrict, or impose
-     conditions on any use of the Licensed Material that could lawfully
-     be made without permission under this Public License.
-
-  b. To the extent possible, if any provision of this Public License is
-     deemed unenforceable, it shall be automatically reformed to the
-     minimum extent necessary to make it enforceable. If the provision
-     cannot be reformed, it shall be severed from this Public License
-     without affecting the enforceability of the remaining terms and
-     conditions.
-
-  c. No term or condition of this Public License will be waived and no
-     failure to comply consented to unless expressly agreed to by the
-     Licensor.
-
-  d. Nothing in this Public License constitutes or may be interpreted
-     as a limitation upon, or waiver of, any privileges and immunities
-     that apply to the Licensor or You, including from the legal
-     processes of any jurisdiction or authority.
-
-
-=======================================================================
-
-Creative Commons is not a party to its public
-licenses. Notwithstanding, Creative Commons may elect to apply one of
-its public licenses to material it publishes and in those instances
-will be considered the "Licensor." The text of the Creative Commons
-public licenses is dedicated to the public domain under the CC0 Public
-Domain Dedication. Except for the limited purpose of indicating that
-material is shared under a Creative Commons public license or as
-otherwise permitted by the Creative Commons policies published at
-creativecommons.org/policies, Creative Commons does not authorize the
-use of the trademark "Creative Commons" or any other trademark or logo
-of Creative Commons without its prior written consent including,
-without limitation, in connection with any unauthorized modifications
-to any of its public licenses or any other arrangements,
-understandings, or agreements concerning use of licensed material. For
-the avoidance of doubt, this paragraph does not form part of the
-public licenses.
-
-Creative Commons may be contacted at creativecommons.org.
\ No newline at end of file
diff --git a/LICENSE.md b/LICENSE.md
index 9ea106dc0..99e03dd69 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,2 +1,602 @@
-Code in this repository is licensed under [Apache License Version 2.0](LICENSE-code) (SPDX-License-Identifier: Apache-2.0).
-Documentation in this repository is licensed under [Creative Common Attribution 4.0 International License](LICENSE-document) (SPDX-License-Identifier: CC-BY-4.0)
\ No newline at end of file
+# License
+
+## Source Code
+
+The source code in this repository is licensed under the MIT License. See below for the full license text.
+
+## Documentation
+
+The documentation in this repository is licensed under the Creative Commons Attribution 4.0 International License. See below for the full license text.
+
+### MIT License
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
+### Creative Commons Attribution 4.0 International License
+
+Attribution 4.0 International
+
+=======================================================================
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and
+does not provide legal services or legal advice. Distribution of
+Creative Commons public licenses does not create a lawyer-client or
+other relationship. Creative Commons makes its licenses and related
+information available on an "as-is" basis. Creative Commons gives no
+warranties regarding its licenses, any material licensed under their
+terms and conditions, or any related information. Creative Commons
+disclaims all liability for damages resulting from their use to the
+fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and
+conditions that creators and other rights holders may use to share
+original works of authorship and other material subject to copyright
+and certain other rights specified in the public license below. The
+following considerations are for informational purposes only, are not
+exhaustive, and do not form part of our licenses.
+
+     Considerations for licensors: Our public licenses are
+     intended for use by those authorized to give the public
+     permission to use material in ways otherwise restricted by
+     copyright and certain other rights. Our licenses are
+     irrevocable. Licensors should read and understand the terms
+     and conditions of the license they choose before applying it.
+     Licensors should also secure all rights necessary before
+     applying our licenses so that the public can reuse the
+     material as expected. Licensors should clearly mark any
+     material not subject to the license. This includes other CC-
+     licensed material, or material used under an exception or
+     limitation to copyright. More considerations for licensors:
+     wiki.creativecommons.org/Considerations_for_licensors
+
+     Considerations for the public: By using one of our public
+     licenses, a licensor grants the public permission to use the
+     licensed material under specified terms and conditions. If
+     the licensor's permission is not necessary for any reason--for
+     example, because of any applicable exception or limitation to
+     copyright--then that use is not regulated by the license. Our
+     licenses grant only permissions under copyright and certain
+     other rights that a licensor has authority to grant. Use of
+     the licensed material may still be restricted for other
+     reasons, including because others have copyright or other
+     rights in the material. A licensor may make special requests,
+     such as asking that all changes be marked or described.
+     Although not required by our licenses, you are encouraged to
+     respect those requests where reasonable. More_considerations
+     for the public: 
+    wiki.creativecommons.org/Considerations_for_licensees
+
+=======================================================================
+
+Creative Commons Attribution 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree
+to be bound by the terms and conditions of this Creative Commons
+Attribution 4.0 International Public License ("Public License"). To the
+extent this Public License may be interpreted as a contract, You are
+granted the Licensed Rights in consideration of Your acceptance of
+these terms and conditions, and the Licensor grants You such rights in
+consideration of benefits the Licensor receives from making the
+Licensed Material available under these terms and conditions.
+
+Section 1 -- Definitions.
+
+  a. Adapted Material means material subject to Copyright and Similar
+     Rights that is derived from or based upon the Licensed Material
+     and in which the Licensed Material is translated, altered,
+     arranged, transformed, or otherwise modified in a manner requiring
+     permission under the Copyright and Similar Rights held by the
+     Licensor. For purposes of this Public License, where the Licensed
+     Material is a musical work, performance, or sound recording,
+     Adapted Material is always produced where the Licensed Material is
+     synched in timed relation with a moving image.
+
+  b. Adapter's License means the license You apply to Your Copyright
+     and Similar Rights in Your contributions to Adapted Material in
+     accordance with the terms and conditions of this Public License.
+
+  c. Copyright and Similar Rights means copyright and/or similar rights
+     closely related to copyright including, without limitation,
+     performance, broadcast, sound recording, and Sui Generis Database
+     Rights, without regard to how the rights are labeled or
+     categorized. For purposes of this Public License, the rights
+     specified in Section 2(b)(1)-(2) are not Copyright and Similar
+     Rights.
+
+  d. Effective Technological Measures means those measures that, in the
+     absence of proper authority, may not be circumvented under laws
+     fulfilling obligations under Article 11 of the WIPO Copyright
+     Treaty adopted on December 20, 1996, and/or similar international
+     agreements.
+
+  e. Exceptions and Limitations means fair use, fair dealing, and/or
+     any other exception or limitation to Copyright and Similar Rights
+     that applies to Your use of the Licensed Material.
+
+  f. Licensed Material means the artistic or literary work, database,
+     or other material to which the Licensor applied this Public
+     License.
+
+  g. Licensed Rights means the rights granted to You subject to the
+     terms and conditions of this Public License, which are limited to
+     all Copyright and Similar Rights that apply to Your use of the
+     Licensed Material and that the Licensor has authority to license.
+
+  h. Licensor means the individual(s) or entity(ies) granting rights
+     under this Public License.
+
+  i. Share means to provide material to the public by any means or
+     process that requires permission under the Licensed Rights, such
+     as reproduction, public display, public performance, distribution,
+     dissemination, communication, or importation, and to make material
+     available to the public including in ways that members of the
+     public may access the material from a place and at a time
+     individually chosen by them.
+
+  j. Sui Generis Database Rights means rights other than copyright
+     resulting from Directive 96/9/EC of the European Parliament and of
+     the Council of 11 March 1996 on the legal protection of databases,
+     as amended and/or succeeded, as well as other essentially
+     equivalent rights anywhere in the world.
+
+  k. You means the individual or entity exercising the Licensed Rights
+     under this Public License. Your has a corresponding meaning.
+
+Section 2 -- Scope.
+
+  a. License grant.
+
+       1. Subject to the terms and conditions of this Public License,
+          the Licensor hereby grants You a worldwide, royalty-free,
+          non-sublicensable, non-exclusive, irrevocable license to
+          exercise the Licensed Rights in the Licensed Material to:
+
+            a. reproduce and Share the Licensed Material, in whole or
+               in part; and
+
+            b. produce, reproduce, and Share Adapted Material.
+
+       2. Exceptions and Limitations. For the avoidance of doubt, where
+          Exceptions and Limitations apply to Your use, this Public
+          License does not apply, and You do not need to comply with
+          its terms and conditions.
+
+       3. Term. The term of this Public License is specified in Section
+          6(a).
+
+       4. Media and formats; technical modifications allowed. The
+          Licensor authorizes You to exercise the Licensed Rights in
+          all media and formats whether now known or hereafter created,
+          and to make technical modifications necessary to do so. The
+          Licensor waives and/or agrees not to assert any right or
+          authority to forbid You from making technical modifications
+          necessary to exercise the Licensed Rights, including
+          technical modifications necessary to circumvent Effective
+          Technological Measures. For purposes of this Public License,
+          simply making modifications authorized by this Section 2(a)
+          (4) never produces Adapted Material.
+
+       5. Downstream recipients.
+
+            a. Offer from the Licensor -- Licensed Material. Every
+               recipient of the Licensed Material automatically
+               receives an offer from the Licensor to exercise the
+               Licensed Rights under the terms and conditions of this
+               Public License.
+
+            b. No downstream restrictions. You may not offer or impose
+               any additional or different terms or conditions on, or
+               apply any Effective Technological Measures to, the
+               Licensed Material if doing so restricts exercise of the
+               Licensed Rights by any recipient of the Licensed
+               Material.
+
+       6. No endorsement. Nothing in this Public License constitutes or
+          may be construed as permission to assert or imply that You
+          are, or that Your use of the Licensed Material is, connected
+          with, or sponsored, endorsed, or granted official status by,
+          the Licensor or others designated to receive attribution as
+          provided in Section 3(a)(1)(A)(i).
+
+  b. Other rights.
+
+       1. Moral rights, such as the right of integrity, are not
+          licensed under this Public License, nor are publicity,
+          privacy, and/or other similar personality rights; however, to
+          the extent possible, the Licensor waives and/or agrees not to
+          assert any such rights held by the Licensor to the limited
+          extent necessary to allow You to exercise the Licensed
+          Rights, but not otherwise.
+
+       2. Patent and trademark rights are not licensed under this
+          Public License.
+
+       3. To the extent possible, the Licensor waives any right to
+          collect royalties from You for the exercise of the Licensed
+          Rights, whether directly or through a collecting society
+          under any voluntary or waivable statutory or compulsory
+          licensing scheme. In all other cases the Licensor expressly
+          reserves any right to collect such royalties.
+
+Section 3 -- License Conditions.
+
+Your exercise of the Licensed Rights is expressly made subject to the
+following conditions.
+
+  a. Attribution.
+
+       1. If You Share the Licensed Material (including in modified
+          form), You must:
+
+            a. retain the following if it is supplied by the Licensor
+               with the Licensed Material:
+
+                 i. identification of the creator(s) of the Licensed
+                    Material and any others designated to receive
+                    attribution, in any reasonable manner requested by
+                    the Licensor (including by pseudonym if
+                    designated);
+
+                ii. a copyright notice;
+
+               iii. a notice that refers to this Public License;
+
+                iv. a notice that refers to the disclaimer of
+                    warranties;
+
+                 v. a URI or hyperlink to the Licensed Material to the
+                    extent reasonably practicable;
+
+            b. indicate if You modified the Licensed Material and
+               retain an indication of any previous modifications; and
+
+            c. indicate the Licensed Material is licensed under this
+               Public License, and include the text of, or the URI or
+               hyperlink to, this Public License.
+
+       2. You may satisfy the conditions in Section 3(a)(1) in any
+          reasonable manner based on the medium, means, and context in
+          which You Share the Licensed Material. For example, it may be
+          reasonable to satisfy the conditions by providing a URI or
+          hyperlink to a resource that includes the required
+          information.
+
+       3. If requested by the Licensor, You must remove any of the
+          information required by Section 3(a)(1)(A) to the extent
+          reasonably practicable.
+
+       4. If You Share Adapted Material You produce, the Adapter's
+          License You apply must not prevent recipients of the Adapted
+          Material from complying with this Public License.
+
+Section 4 -- Sui Generis Database Rights.
+
+Where the Licensed Rights include Sui Generis Database Rights that
+apply to Your use of the Licensed Material:
+
+  a. for the avoidance of doubt, Section 2(a)(1) grants You the right
+     to extract, reuse, reproduce, and Share all or a substantial
+     portion of the contents of the database;
+
+  b. if You include all or a substantial portion of the database
+     contents in a database in which You have Sui Generis Database
+     Rights, then the database in which You have Sui Generis Database
+     Rights (but not its individual contents) is Adapted Material; and
+
+  c. You must comply with the conditions in Section 3(a) if You Share
+     all or a substantial portion of the contents of the database.
+
+For the avoidance of doubt, this Section 4 supplements and does not
+replace Your obligations under this Public License where the Licensed
+Rights include other Copyright and Similar Rights.
+
+Section 5 -- Disclaimer of Warranties and Limitation of Liability.
+
+  a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
+     EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
+     AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
+     ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
+     IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
+     WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
+     PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
+     ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
+     KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
+     ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
+
+  b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
+     TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
+     NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
+     INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
+     COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
+     USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
+     ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
+     DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
+     IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
+
+  c. The disclaimer of warranties and limitation of liability provided
+     above shall be interpreted in a manner that, to the extent
+     possible, most closely approximates an absolute disclaimer and
+     waiver of all liability.
+
+Section 6 -- Term and Termination.
+
+  a. This Public License applies for the term of the Copyright and
+     Similar Rights licensed here. However, if You fail to comply with
+     this Public License, then Your rights under this Public License
+     terminate automatically.
+
+  b. Where Your right to use the Licensed Material has terminated under
+     Section 6(a), it reinstates:
+
+       1. automatically as of the date the violation is cured, provided
+          it is cured within 30 days of Your discovery of the
+          violation; or
+
+       2. upon express reinstatement by the Licensor.
+
+     For the avoidance of doubt, this Section 6(b) does not affect any
+     right the Licensor may have to seek remedies for Your violations
+     of this Public License.
+
+  c. For the avoidance of doubt, the Licensor may also offer the
+     Licensed Material under separate terms or conditions or stop
+     distributing the Licensed Material at any time; however, doing so
+     will not terminate this Public License.
+
+  d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
+     License.
+
+Section 7 -- Other Terms and Conditions.
+
+  a. The Licensor shall not be bound by any additional or different
+     terms or conditions communicated by You unless expressly agreed.
+
+  b. Any arrangements, understandings, or agreements regarding the
+     Licensed Material not stated herein are separate from and
+     independent of the terms and conditions of this Public License.
+
+Section 8 -- Interpretation.
+
+  a. For the avoidance of doubt, this Public License does not, and
+     shall not be interpreted to, reduce, limit, restrict, or impose
+     conditions on any use of the Licensed Material that could lawfully
+     be made without permission under this Public License.
+
+  b. To the extent possible, if any provision of this Public License is
+     deemed unenforceable, it shall be automatically reformed to the
+     minimum extent necessary to make it enforceable. If the provision
+     cannot be reformed, it shall be severed from this Public License
+     without affecting the enforceability of the remaining terms and
+     conditions.
+
+  c. No term or condition of this Public License will be waived and no
+     failure to comply consented to unless expressly agreed to by the
+     Licensor.
+
+  d. Nothing in this Public License constitutes or may be interpreted
+     as a limitation upon, or waiver of, any privileges and immunities
+     that apply to the Licensor or You, including from the legal
+     processes of any jurisdiction or authority.
+
+=======================================================================
+
+Creative Commons is not a party to its public
+licenses. Notwithstanding, Creative Commons may elect to apply one of
+its public licenses to material it publishes and in those instances
+will be considered the "Licensor." The text of the Creative Commons
+public licenses is dedicated to the public domain under the CC0 Public
+Domain Dedication. Except for the limited purpose of indicating that
+material is shared under a Creative Commons public license or as
+otherwise permitted by the Creative Commons policies published at
+creativecommons.org/policies, Creative Commons does not authorize the
+use of the trademark "Creative Commons" or any other trademark or logo
+of Creative Commons without its prior written consent including,
+without limitation, in connection with any unauthorized modifications
+to any of its public licenses or any other arrangements,
+understandings, or agreements concerning use of licensed material. For
+the avoidance of doubt, this paragraph does not form part of the
+public licenses.
+
+Creative Commons may be contacted at creativecommons.org.
diff --git a/Makefile b/Makefile
index 702776dab..788d76203 100644
--- a/Makefile
+++ b/Makefile
@@ -4,24 +4,24 @@ all: setup lint spelling links
 .PHONY: setup
 setup:
 	@echo "Running $@...\n\n"
-	@docker-compose run $@ ci/$@.sh
-	@docker-compose down
+	@docker compose run $@ ci/$@.sh
+	@docker compose down
 
 .PHONY: lint
 lint:
 	@echo "Running $@...\n\n"
-	@docker-compose run $@ ci/$@.sh
-	@docker-compose down
+	@docker compose run $@ ci/$@.sh
+	@docker compose down
 
 .PHONY: spelling
 spelling:
 	@echo "Running $@...\n\n"
-	@docker-compose run $@ ci/$@.sh
-	@docker-compose down
+	@docker compose run $@ ci/$@.sh
+	@docker compose down
 
 .PHONY: links
 links:
 	@echo "Running $@...\n\n"
-	@docker-compose run $@ ci/$@.sh
-	@docker-compose down
+	@docker compose run $@ ci/$@.sh
+	@docker compose down
 
diff --git a/README.md b/README.md
index 21cde8001..c9713d24c 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # Security Technical Advisory Group
 
-![Cloud Native Security Logo](/design/logo/cloud-native-security-horizontal-darkmodesafe.svg)
+![Cloud Native Security Logo](/community/resources/design/logo/cloud-native-security-horizontal-darkmodesafe.svg)
 
 ## Quick links
 
@@ -25,21 +25,21 @@ We aim to significantly reduce the probability and impact of attacks, breaches,
 
 ## Publications
 
-Below is a list of publications by TAG Security. For a comprehensive collection of our works in various formats, please visit the [publications](publications/README.md) directory.
+Below is a list of publications by TAG Security. For a comprehensive collection of our works in various formats, please visit the [publications](community/publications/README.md) directory.
 
 | Publication | Date |
 |-------------|------|
-| [Formal Verification for Policy Configurations](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-formal-verification.md) | August, 2019 |
-| [Catalog of Supply Chain Compromises](https://github.com/cncf/tag-security/tree/main/supply-chain-security/compromises) | November 2019 - Present |
-| [Software Supply Chain Best Practices](https://github.com/cncf/tag-security/raw/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) | May, 2021 |
-| [Evaluating your Supply Chain Security](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md) | May, 2021 |
-| [Cloud Native Security Lexicon](https://github.com/cncf/tag-security/blob/main/security-lexicon/cloud-native-security-lexicon.md) | August, 2021 |
-| [Cloud Native Security Whitepaper](https://www.cncf.io/wp-content/uploads/2022/06/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) | May, 2022 |
-| [Cloud Native Security Controls Catalog](https://github.com/cncf/tag-security/blob/main/cloud-native-controls/phase-one-announcement.md) | May, 2022 |
-| [Handling Build-time Dependency Vulnerabilities](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-build-time-dependency-vulns.md) | June, 2022 |
-| [Secure Software Factory: A Reference Architecture to Securing the Software Supply Chain](https://github.com/cncf/tag-security/raw/main/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) | May, 2022 |
-| [Secure Defaults](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) | February, 2022 |
-| [Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security](https://github.com/cncf/tag-security/blob/main/assessments/Open_and_Secure.pdf) | November, 2023 |
+| [Formal Verification for Policy Configurations](community/working-groups/archive/policy/overview-policy-formal-verification.md) | August, 2019 |
+| [Catalog of Supply Chain Compromises](community/catalog/compromises) | November 2019 - Present |
+| [Software Supply Chain Best Practices](community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) | May, 2021 |
+| [Evaluating your Supply Chain Security](community/working-groups/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md) | May, 2021 |
+| [Cloud Native Security Lexicon](community/resources/security-lexicon/cloud-native-security-lexicon.md) | August, 2021 |
+| [Cloud Native Security Whitepaper](community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) | May, 2022 |
+| [Cloud Native Security Controls Catalog](community/working-groups/controls/phase-one-announcement.md) | May, 2022 |
+| [Handling Build-time Dependency Vulnerabilities](community/working-groups/archive/policy/overview-policy-build-time-dependency-vulns.md) | June, 2022 |
+| [Secure Software Factory: A Reference Architecture to Securing the Software Supply Chain](community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf) | May, 2022 |
+| [Secure Defaults](community/resources/security-whitepaper/secure-defaults-cloud-native-8.md) | February, 2022 |
+| [Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security](community/assessments/Open_and_Secure.pdf) | November, 2023 |
 
 ## Governance
 
@@ -54,24 +54,18 @@ Join our open discussions and share news:
 
 ## Meeting Information
 
-- **Americas**: Weekly on Wednesdays at 10 am (UTC-7). [Zoom link](https://zoom.us/j/99809474566), Meeting ID: 998 0947 4566.
-- **EMEA**: Bi-weekly on Wednesdays at 1 pm UTC+0 (adjusts for daylight saving). [Zoom link](https://zoom.us/j/99917523142), Meeting ID: 999 1752 3142.
+- **Americas**: Weekly on Wednesdays at 10 am (UTC-7). [Zoom link](https://zoom-lfx.platform.linuxfoundation.org/meeting/92340369657?password=76e24ffd-69f2-41a8-8aed-13796805225d), Meeting ID: 923 4036 9657.
+- **EMEA**: Bi-weekly on Wednesdays at 1 pm UTC+0 (adjusts for daylight saving). [Zoom link](https://zoom-lfx.platform.linuxfoundation.org/meeting/98348738138?password=70e6a945-563a-491f-8485-ecf7394ec13a), Meeting ID: 983 4873 8138.
 
 Check your local timezone [here](https://time.is/). Meetings are listed on the [CNCF calendar](https://www.cncf.io/calendar/) and the [TAG Security Calendar](https://calendar.google.com/calendar/u/0?cid=MGI4dTVlbDh0YTRzOTN0MmNtNzJ0dXZoaGtAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ).
 
 To add a topic to the agenda, review our [process](governance/process.md#getting-on-the-agenda).
 
-## Gatherings
-
-- [Cloud Native SecurityCon 24](https://events.linuxfoundation.org/cloudnativesecuritycon-north-america/) June 26-27, 2024 in Seattle, Washington
-- [Past events](past-events.md)
-
 ## New members
 
 If you are new to the group, we encourage you to check out our
 [contributing guidelines](CONTRIBUTING.md).
 
-
 ## Related groups
 
 Explore groups affiliated with or relevant to Security TAG [here](governance/related-groups/README.md)
@@ -80,36 +74,13 @@ Explore groups affiliated with or relevant to Security TAG [here](governance/rel
 
 <!-- cSpell:disable -->
 
-### 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
 
@@ -119,13 +90,12 @@ Each group, led by a responsible leader, reaches consensus on issues and manages
 
 | Project | Leads |
 |---------------------------------|---------------------------------------------|
-| [Research](/community/research/README.md) | Andrés Vega |
-| [Automated Governance](/community/automated-governance/README.md) | Andrés Vega, Brandt Keller |
+| [Automated Governance](/community/working-groups/automated-governance/README.md) | Matthew Flannery, Brandt Keller |
 | [Catalog of Supply Chain Compromises](/community/catalog/README.md) | Santiago Arias Torres |
-| [Compliance](/community/compliance/README.md) | Anca Sailer, Robert Ficcaglia |
-| [Controls](/community/controls/README.md) | Jon Zeolla |
-| [Security Reviews](/assessments/README.md) | Justin Cappos, Eddie Knight|
-| [Software Supply Chain](/community/supply-chain-security/README.md) | Marina Moore, Michael Liebermann, John Kjell |
+| [Compliance](/community/working-groups/compliance/README.md) | Anca Sailer, Robert Ficcaglia |
+| [Controls](/community/working-groups/controls/README.md) | Jon Zeolla |
+| [Security Reviews](/community/assessments/README.md) | Justin Cappos, Eddie Knight|
+| [Software Supply Chain](/community/working-groups/supply-chain-security/README.md) | Marina Moore, Michael Liebermann, John Kjell |
 
 ## Additional information
 
@@ -135,5 +105,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](./assessments/guide/self-assessment.md)
-.
+[self-assessment](/community/assessments/guide/self-assessment.md).
diff --git a/ci/link-config.json b/ci/link-config.json
index 0e43c9de4..95daf4d03 100644
--- a/ci/link-config.json
+++ b/ci/link-config.json
@@ -1,5 +1,5 @@
 {
-    "aliveStatusCodes": [200,206,402],
+    "aliveStatusCodes": [200,206,402,999],
     "fallbackRetryDelay": "10s",
     "replacementPatterns": [
       {
diff --git a/ci/spelling-config.json b/ci/spelling-config.json
index b8243b39a..2d2989db1 100644
--- a/ci/spelling-config.json
+++ b/ci/spelling-config.json
@@ -8,13 +8,17 @@
     "words": [
         "ABAC",
         "addfetnetgrent",
+        "Aniszczyk",
         "antifragile",
         "APAC",
         "archives",
+        "ARMO",
         "ATT&CK",
         "backdoors",
+        "Benedictis",
         "Buildpacks",
         "BYOK",
+        "Cappos",
         "cgroups",
         "chainguard",
         "cisecurity",
@@ -22,6 +26,7 @@
         "cloudcustodian",
         "CMMC",
         "CNCF",
+        "CNSC",
         "CNSMAP",
         "CNSWP",
         "CNSWP's",
@@ -29,6 +34,7 @@
         "CODEOWNERS",
         "Configu",
         "conftest",
+        "Conjur",
         "coreutils",
         "CrowdStrike",
         "cryptomining",
@@ -46,17 +52,24 @@
         "exfiltrate",
         "exfiltration",
         "explainability",
+        "exploitability",
         "Expressibility",
         "Fianu",
         "FIPS",
         "Flibble",
+        "frontmatter",
         "Gamal",
         "gconv",
+        "gitsign",
+        "gittuf",
+        "GUAC",
         "helm",
         "HIPAA",
         "HITRUST",
+        "Hirschberg",
         "hotspots",
         "hyperconverged",
+        "Inclusivity",
         "intercompatible",
         "iscsi",
         "Istio",
@@ -69,6 +82,7 @@
         "Kube",
         "kubecon",
         "Kubernetes",
+        "Kubescape",
         "Kyverno",
         "libc",
         "libgcrypt",
@@ -102,11 +116,16 @@
         "PEAR",
         "pearweb",
         "PHP",
+        "Pronin",
         "protobuf",
         "ptree",
         "pyproject",
+        "Ragashree",
+        "Razzak",
         "RBAC",
+        "RCOS",
         "Rego",
+        "Rensselaer",
         "Roadmap",
         "runtimes",
         "sandboxed",
@@ -117,6 +136,8 @@
         "sdlc",
         "seccomp",
         "semgrep",
+        "Sergey",
+        "Shlomo",
         "Sigstore",
         "SLSA",
         "snyk",
@@ -133,6 +154,7 @@
         "Syft",
         "syscall",
         "TAR",
+        "timeframe",
         "TOCTOU",
         "toolset",
         "triage",
@@ -150,6 +172,8 @@
         "usecase",
         "venv",
         "Virtool",
-        "Wolt"
+        "Wolt",
+        "Yubi",
+        "Zalman"
     ]
 }
diff --git a/community/README.md b/community/README.md
index 30f6c609a..2eacef666 100644
--- a/community/README.md
+++ b/community/README.md
@@ -1,3 +1,40 @@
-# TAG-Security Community Activities
+# Community Directory
 
-The Security TAG has several working groups that organize community activities around specific topics, including recurring meetings.
+Welcome to the Community Directory of the CNCF TAG Security repository. This directory is a central hub for all community-related activities, documents, and resources. It is organized to facilitate collaboration, provide information, and support the various working groups and events within the TAG Security community.
+
+## Directory Structure
+
+### Catalog
+
+- Contains the catalog of supply chain compromises.
+
+### Publications
+
+- Index of published papers, reports, whitepapers, and audio versions of publications. The source files are located in:
+  - **resources/** if they are overarching documents.
+  - **community/working-groups/** if they are owned by a working group.
+  - **assessments/** if they are assessment documents.
+
+### Working Groups
+
+- **archive/policy/**: Contains archived Policy-as-Code assets.
+- **automated-governance/**: Assets for the Automated Governance working group.
+- **compliance/**: Assets for the Compliance working group.
+- **controls/**: Assets for the Controls working group.
+- **research/**: Assets related to the Research working group.
+- **supply-chain-security/**: Resources and documents for the Supply Chain Security working group.
+- **catalog/**: Contains the catalog of working group activities and documents.
+
+### Events
+
+- Information about past and future community gatherings.
+
+### Community Resources
+
+- **Design**: Colors and logos used in documents and presentations.
+- **Overarching Publications**: Cloud Native Security Landscape, Provenance Implementation Guides, Security Fuzzing Handbook, Lexicon, White Paper, and Use Case Personas.
+- **Project Resources/**: Contains various project-specific resources and templates.
+
+## Contribution Guidelines
+
+We welcome contributions to this directory. Please follow the general contribution guidelines outlined in the root `CONTRIBUTING.md` file of this repository. Ensure that your contributions align with the purpose of each subdirectory and provide clear and useful information for community members.
diff --git a/community/assessments/guide/README.md b/community/assessments/guide/README.md
index 0f7a0085b..f87ad5cbb 100644
--- a/community/assessments/guide/README.md
+++ b/community/assessments/guide/README.md
@@ -66,7 +66,7 @@ feel important in an updated self-assessment based on feedback and discussion.
 
 After the presentation, the **project lead** or their designee should submit a
 PR, citing the presentation issue number to add the self-assessment to
-[assessments/projects](https://github.com/cncf/tag-security/tree/main/assessments/projects)
+[assessments/projects](/community/assessments/projects)
 under its own folder.  The ticket may then be closed after merged in.
 
 ### Growing projects
diff --git a/community/assessments/guide/joint-readme-template.md b/community/assessments/guide/joint-readme-template.md
index 43abdafa2..478b17668 100644
--- a/community/assessments/guide/joint-readme-template.md
+++ b/community/assessments/guide/joint-readme-template.md
@@ -27,7 +27,7 @@ _Use cases, integrations, etc. bulleted, should be available in the joint assess
 
 ## Recommendations
 
-_refer to the existing readmes for other projects, such as [SPIFFE/SPIRE](https://github.com/cncf/tag-security/tree/main/assessments/projects/spiffe-spire) as a guide for developing this area_
+_refer to the existing readmes for other projects, such as [SPIFFE/SPIRE](/community/assessments/projects/spiffe-spire) as a guide for developing this area_
 
 ### CNCF recommendations
 
diff --git a/community/assessments/projects/cloudevents/self-assessment.md b/community/assessments/projects/cloudevents/self-assessment.md
index 7b3a5eef2..98bdeb135 100644
--- a/community/assessments/projects/cloudevents/self-assessment.md
+++ b/community/assessments/projects/cloudevents/self-assessment.md
@@ -951,4 +951,4 @@ including more physical areas such as mechanical engineering and factories.
 * [Sample Security
   Assessment](https://github.com/Rana-KV/tag-security/blob/main/assessments/projects/karmada/self-assessment.md#threat-modeling-with-stride)
 * [Open and Secure
-  Book](https://github.com/cncf/tag-security/blob/main/assessments/Open_and_Secure.pdf)
+  Book](/community/assessments/Open_and_Secure.pdf)
diff --git a/community/assessments/projects/dragonfly/images/arch.png b/community/assessments/projects/dragonfly/images/arch.png
new file mode 100644
index 000000000..57f9617be
Binary files /dev/null and b/community/assessments/projects/dragonfly/images/arch.png differ
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                | <https://github.com/dragonflyoss/Dragonfly2/blob/main/SECURITY.md> |
+| Default and optional configs | <https://d7y.io/docs/>                                             |
+
+## 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 <dragonfly-maintainers@googlegroups.com>.
+- Report the security issue with the detailed information, such as the description of the vulnerability,
+  the steps to reproduce the vulnerability through the <https://github.com/dragonflyoss/Dragonfly2/issues>.
+- 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 <https://bestpractices.coreinfrastructure.org/projects/7103>.
+
+### Case Studies
+
+- Volcano Engine - <https://www.cncf.io/blog/2023/04/13/volcano-engine-distributed-image-acceleration-practice-based-on-dragonfly/>
+- KuaiShou - <https://www.cncf.io/case-studies/kuaishou-technology/>
+- Ant Group - <https://www.cncf.io/blog/2023/05/01/ant-group-security-technologys-nydus-and-dragonfly-image-acceleration-practices/>
+- CoreWeave - <https://docs.coreweave.com/cloud-tools/nydus>
+
+### 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.
diff --git a/community/assessments/projects/flatcar/self-assessment.md b/community/assessments/projects/flatcar/self-assessment.md
index 3aed0c588..bae2d2515 100644
--- a/community/assessments/projects/flatcar/self-assessment.md
+++ b/community/assessments/projects/flatcar/self-assessment.md
@@ -12,7 +12,7 @@ Authors: Danielle Tal and Thilo Fromm
 
 [the Appendix](#heading=h.7dxoyq24wwg8))
 
-This self-assessment thoroughly reflects on Flatcar Container Linux’ security mechanisms and processes, and lists and assesses security documentation. The document aims to provide a foundation for a [joint security review](https://github.com/cncf/tag-security/blob/main/assessments/guide/joint-assessment.md) of the Flatcar project; target audience is [joint assessment reviewers](https://github.com/cncf/tag-security/blob/main/assessments/guide/security-reviewer.md).
+This self-assessment thoroughly reflects on Flatcar Container Linux’ security mechanisms and processes, and lists and assesses security documentation. The document aims to provide a foundation for a [joint security review](/community/assessments/guide/joint-assessment.md) of the Flatcar project; target audience is [joint assessment reviewers](/community/assessments/guide/security-reviewer.md).
 
 
 # Metadata
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.
+
+<!-- n.b the below table is line wrapped by the linter on this repo, which is
+mutually exclusive with markdown table syntax -->
+
+|   |  |
+| -- | -- |
+| 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<br>TA0003: Persistence -> T1078: Valid Accounts<br>TA0004: Privilege Escalation -> T1078: Valid Accounts|
+|Actors|openfga.server|
+|Suggested Mitigation|Secrets mounted in filesystem can be restricted with permissions. Alternatively, <br>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.<br>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. <br>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<br>TA0001: Initial Access -> T1189: Drive-by Compromise|
+|Actors|openfga.server|
+|Suggested Mitigation|Already bring addresed by project team - <a href="https://github.com/openfga/roadmap/issues/7">https://github.com/openfga/roadmap/issues/7</a>.<br>Documentation is clear to disable playground for prod deployments.<br>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<br>TA0003: Persistence -> T1098: Account Manipulation<br>TA0004: Privilege Escalation -> T1548: Abuse Elevation Control Mechanism<br>TA0004: Privilege Escalation -> T1134: Access Token Manipulation<br>TA0004: Privilege Escalation -> T1098: Account Manipulation<br>TA0004: Privilege Escalation -> T1611: Escape to Host<br>TA0005: Defense Evasion -> T1548: Abuse Elevation Control Mechanism<br>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?<br>In the case of helm chart, this would achieve: <ol><li>Not running server as root</li> <li>Not allowing privilege escalation</li> <li>Not allowing access to system calls unless required</li> <li>Setting filesystem to readonly </li> <li>Limiting access to mounted filesystems</li></ol><br>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?<br>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.<br>Also, many sites will use email ID as primary login, documentation may need to address how to handle this situation.<br>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.<br> 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)<br>- [Pull Request Workflow](https://github.com/openfga/openfga/blob/main/.github/workflows/pull_request.yaml)<br>- 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.**
+
+<!-- Commented out in case a hands-on assessment is requested and performed
+*If a hands-on assessment was performed, the below format should be used for
+reporting details*
+
+| | |
+| -- | -- |
+| Date of assessment | mmddyyyy-mmddyyyy |
+| Hands-on reviewers | name, github handle |
+
+| Finding Number | Finding name | Finding Notes | Reviewer |
+| -- | -- | -- | -- |
+| | | |
+
+### Hands-on assessment result
+
+General comments and summary of the hands-on assessment with any recommendations
+worth noting.  If nothing found use the below example:
+
+> TAG-Security's hands-on assessment did not reveal any significant or notable
+security findings for OpenFGA. This outcome does not indicate that none exist,
+rather that none were discovered.
+-->
+
+## 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)
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!
+
+<!-- cSpell:disable -->
+
+| 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|
+
+<!-- cSpell:disable -->
diff --git a/community/catalog/README.md b/community/catalog/README.md
index 0b4f3298b..87db212d1 100644
--- a/community/catalog/README.md
+++ b/community/catalog/README.md
@@ -2,7 +2,7 @@
 
 The Catalog of Supply Chain Compromises provides real-world examples that help raise awareness and provide detailed information that lets us understand attack vectors and consider how to mitigate potential risk.
 
-For information on how to contribute, check the [catalog](/supply-chain-security/compromises) directly.
+For information on how to contribute, check the [catalog](./compromises/) directly.
 
 ## Contact
 
diff --git a/supply-chain-security/compromises/1975/login-bell.md b/community/catalog/compromises/1975/login-bell.md
similarity index 100%
rename from supply-chain-security/compromises/1975/login-bell.md
rename to community/catalog/compromises/1975/login-bell.md
diff --git a/supply-chain-security/compromises/2003/debian.md b/community/catalog/compromises/2003/debian.md
similarity index 100%
rename from supply-chain-security/compromises/2003/debian.md
rename to community/catalog/compromises/2003/debian.md
diff --git a/supply-chain-security/compromises/2003/gentoo-rsync.md b/community/catalog/compromises/2003/gentoo-rsync.md
similarity index 100%
rename from supply-chain-security/compromises/2003/gentoo-rsync.md
rename to community/catalog/compromises/2003/gentoo-rsync.md
diff --git a/supply-chain-security/compromises/2003/kernel-repository.md b/community/catalog/compromises/2003/kernel-repository.md
similarity index 100%
rename from supply-chain-security/compromises/2003/kernel-repository.md
rename to community/catalog/compromises/2003/kernel-repository.md
diff --git a/supply-chain-security/compromises/2007/squirrelmail.md b/community/catalog/compromises/2007/squirrelmail.md
similarity index 100%
rename from supply-chain-security/compromises/2007/squirrelmail.md
rename to community/catalog/compromises/2007/squirrelmail.md
diff --git a/supply-chain-security/compromises/2007/wordpress.md b/community/catalog/compromises/2007/wordpress.md
similarity index 100%
rename from supply-chain-security/compromises/2007/wordpress.md
rename to community/catalog/compromises/2007/wordpress.md
diff --git a/supply-chain-security/compromises/2008/fedora.md b/community/catalog/compromises/2008/fedora.md
similarity index 100%
rename from supply-chain-security/compromises/2008/fedora.md
rename to community/catalog/compromises/2008/fedora.md
diff --git a/supply-chain-security/compromises/2010/apache.md b/community/catalog/compromises/2010/apache.md
similarity index 100%
rename from supply-chain-security/compromises/2010/apache.md
rename to community/catalog/compromises/2010/apache.md
diff --git a/supply-chain-security/compromises/2010/aurora.md b/community/catalog/compromises/2010/aurora.md
similarity index 100%
rename from supply-chain-security/compromises/2010/aurora.md
rename to community/catalog/compromises/2010/aurora.md
diff --git a/supply-chain-security/compromises/2010/fsf-website.md b/community/catalog/compromises/2010/fsf-website.md
similarity index 100%
rename from supply-chain-security/compromises/2010/fsf-website.md
rename to community/catalog/compromises/2010/fsf-website.md
diff --git a/supply-chain-security/compromises/2010/proftpd.md b/community/catalog/compromises/2010/proftpd.md
similarity index 100%
rename from supply-chain-security/compromises/2010/proftpd.md
rename to community/catalog/compromises/2010/proftpd.md
diff --git a/supply-chain-security/compromises/2011/kernelorg.md b/community/catalog/compromises/2011/kernelorg.md
similarity index 100%
rename from supply-chain-security/compromises/2011/kernelorg.md
rename to community/catalog/compromises/2011/kernelorg.md
diff --git a/supply-chain-security/compromises/2012/ruby-on-rails-github.md b/community/catalog/compromises/2012/ruby-on-rails-github.md
similarity index 100%
rename from supply-chain-security/compromises/2012/ruby-on-rails-github.md
rename to community/catalog/compromises/2012/ruby-on-rails-github.md
diff --git a/supply-chain-security/compromises/2013/apt.md b/community/catalog/compromises/2013/apt.md
similarity index 100%
rename from supply-chain-security/compromises/2013/apt.md
rename to community/catalog/compromises/2013/apt.md
diff --git a/supply-chain-security/compromises/2014/code-spaces.md b/community/catalog/compromises/2014/code-spaces.md
similarity index 100%
rename from supply-chain-security/compromises/2014/code-spaces.md
rename to community/catalog/compromises/2014/code-spaces.md
diff --git a/supply-chain-security/compromises/2014/monju.md b/community/catalog/compromises/2014/monju.md
similarity index 100%
rename from supply-chain-security/compromises/2014/monju.md
rename to community/catalog/compromises/2014/monju.md
diff --git a/supply-chain-security/compromises/2015/ceph-and-inktank.md b/community/catalog/compromises/2015/ceph-and-inktank.md
similarity index 100%
rename from supply-chain-security/compromises/2015/ceph-and-inktank.md
rename to community/catalog/compromises/2015/ceph-and-inktank.md
diff --git a/supply-chain-security/compromises/2015/juniper.md b/community/catalog/compromises/2015/juniper.md
similarity index 100%
rename from supply-chain-security/compromises/2015/juniper.md
rename to community/catalog/compromises/2015/juniper.md
diff --git a/supply-chain-security/compromises/2015/xcodeghost.md b/community/catalog/compromises/2015/xcodeghost.md
similarity index 100%
rename from supply-chain-security/compromises/2015/xcodeghost.md
rename to community/catalog/compromises/2015/xcodeghost.md
diff --git a/supply-chain-security/compromises/2016/fosshub.md b/community/catalog/compromises/2016/fosshub.md
similarity index 100%
rename from supply-chain-security/compromises/2016/fosshub.md
rename to community/catalog/compromises/2016/fosshub.md
diff --git a/supply-chain-security/compromises/2016/gh-unicode.md b/community/catalog/compromises/2016/gh-unicode.md
similarity index 100%
rename from supply-chain-security/compromises/2016/gh-unicode.md
rename to community/catalog/compromises/2016/gh-unicode.md
diff --git a/supply-chain-security/compromises/2016/keydnap.md b/community/catalog/compromises/2016/keydnap.md
similarity index 100%
rename from supply-chain-security/compromises/2016/keydnap.md
rename to community/catalog/compromises/2016/keydnap.md
diff --git a/supply-chain-security/compromises/2016/mint.md b/community/catalog/compromises/2016/mint.md
similarity index 100%
rename from supply-chain-security/compromises/2016/mint.md
rename to community/catalog/compromises/2016/mint.md
diff --git a/supply-chain-security/compromises/2017/bitcoingold.md b/community/catalog/compromises/2017/bitcoingold.md
similarity index 100%
rename from supply-chain-security/compromises/2017/bitcoingold.md
rename to community/catalog/compromises/2017/bitcoingold.md
diff --git a/supply-chain-security/compromises/2017/ccleaner.md b/community/catalog/compromises/2017/ccleaner.md
similarity index 100%
rename from supply-chain-security/compromises/2017/ccleaner.md
rename to community/catalog/compromises/2017/ccleaner.md
diff --git a/supply-chain-security/compromises/2017/elmedia.md b/community/catalog/compromises/2017/elmedia.md
similarity index 100%
rename from supply-chain-security/compromises/2017/elmedia.md
rename to community/catalog/compromises/2017/elmedia.md
diff --git a/supply-chain-security/compromises/2017/expensivewall.md b/community/catalog/compromises/2017/expensivewall.md
similarity index 100%
rename from supply-chain-security/compromises/2017/expensivewall.md
rename to community/catalog/compromises/2017/expensivewall.md
diff --git a/supply-chain-security/compromises/2017/hacktask.md b/community/catalog/compromises/2017/hacktask.md
similarity index 100%
rename from supply-chain-security/compromises/2017/hacktask.md
rename to community/catalog/compromises/2017/hacktask.md
diff --git a/supply-chain-security/compromises/2017/handbrake.md b/community/catalog/compromises/2017/handbrake.md
similarity index 100%
rename from supply-chain-security/compromises/2017/handbrake.md
rename to community/catalog/compromises/2017/handbrake.md
diff --git a/supply-chain-security/compromises/2017/kingslayer.md b/community/catalog/compromises/2017/kingslayer.md
similarity index 100%
rename from supply-chain-security/compromises/2017/kingslayer.md
rename to community/catalog/compromises/2017/kingslayer.md
diff --git a/supply-chain-security/compromises/2017/notpetya.md b/community/catalog/compromises/2017/notpetya.md
similarity index 100%
rename from supply-chain-security/compromises/2017/notpetya.md
rename to community/catalog/compromises/2017/notpetya.md
diff --git a/supply-chain-security/compromises/2018/aur.md b/community/catalog/compromises/2018/aur.md
similarity index 100%
rename from supply-chain-security/compromises/2018/aur.md
rename to community/catalog/compromises/2018/aur.md
diff --git a/supply-chain-security/compromises/2018/colourama.md b/community/catalog/compromises/2018/colourama.md
similarity index 100%
rename from supply-chain-security/compromises/2018/colourama.md
rename to community/catalog/compromises/2018/colourama.md
diff --git a/supply-chain-security/compromises/2018/dofoil.md b/community/catalog/compromises/2018/dofoil.md
similarity index 100%
rename from supply-chain-security/compromises/2018/dofoil.md
rename to community/catalog/compromises/2018/dofoil.md
diff --git a/supply-chain-security/compromises/2018/event_stream.md b/community/catalog/compromises/2018/event_stream.md
similarity index 100%
rename from supply-chain-security/compromises/2018/event_stream.md
rename to community/catalog/compromises/2018/event_stream.md
diff --git a/supply-chain-security/compromises/2018/gentoo.md b/community/catalog/compromises/2018/gentoo.md
similarity index 100%
rename from supply-chain-security/compromises/2018/gentoo.md
rename to community/catalog/compromises/2018/gentoo.md
diff --git a/supply-chain-security/compromises/2018/gogetu.md b/community/catalog/compromises/2018/gogetu.md
similarity index 100%
rename from supply-chain-security/compromises/2018/gogetu.md
rename to community/catalog/compromises/2018/gogetu.md
diff --git a/supply-chain-security/compromises/2018/operation-red.md b/community/catalog/compromises/2018/operation-red.md
similarity index 100%
rename from supply-chain-security/compromises/2018/operation-red.md
rename to community/catalog/compromises/2018/operation-red.md
diff --git a/supply-chain-security/compromises/2018/unnamed-maker.md b/community/catalog/compromises/2018/unnamed-maker.md
similarity index 100%
rename from supply-chain-security/compromises/2018/unnamed-maker.md
rename to community/catalog/compromises/2018/unnamed-maker.md
diff --git a/supply-chain-security/compromises/2019/canonical-github.md b/community/catalog/compromises/2019/canonical-github.md
similarity index 100%
rename from supply-chain-security/compromises/2019/canonical-github.md
rename to community/catalog/compromises/2019/canonical-github.md
diff --git a/supply-chain-security/compromises/2019/electron-native-notify.md b/community/catalog/compromises/2019/electron-native-notify.md
similarity index 100%
rename from supply-chain-security/compromises/2019/electron-native-notify.md
rename to community/catalog/compromises/2019/electron-native-notify.md
diff --git a/supply-chain-security/compromises/2019/monero.md b/community/catalog/compromises/2019/monero.md
similarity index 94%
rename from supply-chain-security/compromises/2019/monero.md
rename to community/catalog/compromises/2019/monero.md
index 4e7ae73b4..63b408581 100644
--- a/supply-chain-security/compromises/2019/monero.md
+++ b/community/catalog/compromises/2019/monero.md
@@ -19,4 +19,4 @@ This incident fits the [Publishing Infrastructure](../compromise-definitions.md#
 
 - [Warning: The binaries of the CLI wallet were compromised for a short time](https://web.getmonero.org/2019/11/19/warning-compromised-binaries.html)
 - [Wrong hashes (from getmonero.org)](https://github.com/monero-project/monero/issues/6151)
-- [Security Warning: CLI binaries available on getmonero.org may have been compromised at some point during the last 24h.](https://old.reddit.com/r/Monero/comments/dyfozs/security_warning_cli_binaries_available_on/)
\ No newline at end of file
+- [Security Warning: CLI binaries available on getmonero.org may have been compromised at some point during the last 24h.](https://www.reddit.com/r/Monero/comments/dyfozs/security_warning_cli_binaries_available_on/)
\ No newline at end of file
diff --git a/supply-chain-security/compromises/2019/pear.md b/community/catalog/compromises/2019/pear.md
similarity index 100%
rename from supply-chain-security/compromises/2019/pear.md
rename to community/catalog/compromises/2019/pear.md
diff --git a/supply-chain-security/compromises/2019/purescript-npm.md b/community/catalog/compromises/2019/purescript-npm.md
similarity index 100%
rename from supply-chain-security/compromises/2019/purescript-npm.md
rename to community/catalog/compromises/2019/purescript-npm.md
diff --git a/supply-chain-security/compromises/2019/pypi.md b/community/catalog/compromises/2019/pypi.md
similarity index 100%
rename from supply-chain-security/compromises/2019/pypi.md
rename to community/catalog/compromises/2019/pypi.md
diff --git a/supply-chain-security/compromises/2019/ros.md b/community/catalog/compromises/2019/ros.md
similarity index 100%
rename from supply-chain-security/compromises/2019/ros.md
rename to community/catalog/compromises/2019/ros.md
diff --git a/supply-chain-security/compromises/2019/shadowhammer.md b/community/catalog/compromises/2019/shadowhammer.md
similarity index 100%
rename from supply-chain-security/compromises/2019/shadowhammer.md
rename to community/catalog/compromises/2019/shadowhammer.md
diff --git a/supply-chain-security/compromises/2019/webmin-backdoor.md b/community/catalog/compromises/2019/webmin-backdoor.md
similarity index 100%
rename from supply-chain-security/compromises/2019/webmin-backdoor.md
rename to community/catalog/compromises/2019/webmin-backdoor.md
diff --git a/supply-chain-security/compromises/2020/nodejs.md b/community/catalog/compromises/2020/nodejs.md
similarity index 100%
rename from supply-chain-security/compromises/2020/nodejs.md
rename to community/catalog/compromises/2020/nodejs.md
diff --git a/supply-chain-security/compromises/2020/octopus_scanner.md b/community/catalog/compromises/2020/octopus_scanner.md
similarity index 100%
rename from supply-chain-security/compromises/2020/octopus_scanner.md
rename to community/catalog/compromises/2020/octopus_scanner.md
diff --git a/supply-chain-security/compromises/2020/solarwinds.md b/community/catalog/compromises/2020/solarwinds.md
similarity index 100%
rename from supply-chain-security/compromises/2020/solarwinds.md
rename to community/catalog/compromises/2020/solarwinds.md
diff --git a/supply-chain-security/compromises/2020/sonarqube.md b/community/catalog/compromises/2020/sonarqube.md
similarity index 100%
rename from supply-chain-security/compromises/2020/sonarqube.md
rename to community/catalog/compromises/2020/sonarqube.md
diff --git a/supply-chain-security/compromises/2020/thegreatsuspender.md b/community/catalog/compromises/2020/thegreatsuspender.md
similarity index 97%
rename from supply-chain-security/compromises/2020/thegreatsuspender.md
rename to community/catalog/compromises/2020/thegreatsuspender.md
index 67a44b240..0cf51a7a3 100644
--- a/supply-chain-security/compromises/2020/thegreatsuspender.md
+++ b/community/catalog/compromises/2020/thegreatsuspender.md
@@ -20,10 +20,12 @@ diverged from its Github source. A minor change in the manifest was now being
 shipped on the chrome web store, which was not included in Github. This is a
 major concern.
 
+<!-- markdown-link-check-disable -->
 As a final red flag, no part of the web-store posting has been updated to account
 for this. [@greatsuspender](https://github.com/greatsuspender) remains listed as
-the maintainer, and the privacy policy makes no mention of the new tracking or
+the maintainer, and a privacy policy makes no mention of the new tracking or
 maintainer [greatsuspender privacy policy](https://greatsuspender.github.io/privacy).
+<!-- markdown-link-check-disable -->
 
 On November 6th, [@lucasdf](https://github.com/lucasdf) discovered a smoking gun
 that the new maintainer is malicious. Although OpenWebAnalytics is legitimate
diff --git a/supply-chain-security/compromises/2020/trojanized-fdm.md b/community/catalog/compromises/2020/trojanized-fdm.md
similarity index 100%
rename from supply-chain-security/compromises/2020/trojanized-fdm.md
rename to community/catalog/compromises/2020/trojanized-fdm.md
diff --git a/supply-chain-security/compromises/2021/coa-rc.md b/community/catalog/compromises/2021/coa-rc.md
similarity index 100%
rename from supply-chain-security/compromises/2021/coa-rc.md
rename to community/catalog/compromises/2021/coa-rc.md
diff --git a/supply-chain-security/compromises/2021/codecov.md b/community/catalog/compromises/2021/codecov.md
similarity index 100%
rename from supply-chain-security/compromises/2021/codecov.md
rename to community/catalog/compromises/2021/codecov.md
diff --git a/supply-chain-security/compromises/2021/homebrew.md b/community/catalog/compromises/2021/homebrew.md
similarity index 100%
rename from supply-chain-security/compromises/2021/homebrew.md
rename to community/catalog/compromises/2021/homebrew.md
diff --git a/supply-chain-security/compromises/2021/klow-klown-okhsa.md b/community/catalog/compromises/2021/klow-klown-okhsa.md
similarity index 100%
rename from supply-chain-security/compromises/2021/klow-klown-okhsa.md
rename to community/catalog/compromises/2021/klow-klown-okhsa.md
diff --git a/supply-chain-security/compromises/2021/log4j.md b/community/catalog/compromises/2021/log4j.md
similarity index 100%
rename from supply-chain-security/compromises/2021/log4j.md
rename to community/catalog/compromises/2021/log4j.md
diff --git a/supply-chain-security/compromises/2021/php.md b/community/catalog/compromises/2021/php.md
similarity index 100%
rename from supply-chain-security/compromises/2021/php.md
rename to community/catalog/compromises/2021/php.md
diff --git a/supply-chain-security/compromises/2021/repojacking.md b/community/catalog/compromises/2021/repojacking.md
similarity index 100%
rename from supply-chain-security/compromises/2021/repojacking.md
rename to community/catalog/compromises/2021/repojacking.md
diff --git a/supply-chain-security/compromises/2021/travis-ci.md b/community/catalog/compromises/2021/travis-ci.md
similarity index 100%
rename from supply-chain-security/compromises/2021/travis-ci.md
rename to community/catalog/compromises/2021/travis-ci.md
diff --git a/supply-chain-security/compromises/2021/ua-parser-js.md b/community/catalog/compromises/2021/ua-parser-js.md
similarity index 100%
rename from supply-chain-security/compromises/2021/ua-parser-js.md
rename to community/catalog/compromises/2021/ua-parser-js.md
diff --git a/supply-chain-security/compromises/2021/vscode.md b/community/catalog/compromises/2021/vscode.md
similarity index 100%
rename from supply-chain-security/compromises/2021/vscode.md
rename to community/catalog/compromises/2021/vscode.md
diff --git a/supply-chain-security/compromises/2022/Comm100-live-chat-trojan.md b/community/catalog/compromises/2022/Comm100-live-chat-trojan.md
similarity index 100%
rename from supply-chain-security/compromises/2022/Comm100-live-chat-trojan.md
rename to community/catalog/compromises/2022/Comm100-live-chat-trojan.md
diff --git a/supply-chain-security/compromises/2022/auth0-source-code-leak.md b/community/catalog/compromises/2022/auth0-source-code-leak.md
similarity index 91%
rename from supply-chain-security/compromises/2022/auth0-source-code-leak.md
rename to community/catalog/compromises/2022/auth0-source-code-leak.md
index 166f042e5..a4b69faf2 100644
--- a/supply-chain-security/compromises/2022/auth0-source-code-leak.md
+++ b/community/catalog/compromises/2022/auth0-source-code-leak.md
@@ -13,7 +13,7 @@ to Okta environments.
 
 It's not entirely clear what the type of compromise is here. It appears to be
 source code like the [Intel BIOS
-leak](/supply-chain-security/compromises/2022/intel-alder-lake-BIOS-leak.md) and
+leak](community/catalog/compromises/2022/intel-alder-lake-BIOS-leak.md) and
 might also involve dev tooling depending on how the attacker gained access to
 the source code.
 
diff --git a/supply-chain-security/compromises/2022/ctx-and-phpass.md b/community/catalog/compromises/2022/ctx-and-phpass.md
similarity index 93%
rename from supply-chain-security/compromises/2022/ctx-and-phpass.md
rename to community/catalog/compromises/2022/ctx-and-phpass.md
index 224d8a8c4..e3cdc0443 100644
--- a/supply-chain-security/compromises/2022/ctx-and-phpass.md
+++ b/community/catalog/compromises/2022/ctx-and-phpass.md
@@ -19,6 +19,8 @@ This incident fits the [Dev Tooling](../compromise-definitions.md#dev-tooling) d
 
 ## References
 
+<!-- markdown-link-check-disable -->
 - [How I hacked CTX and PHPass Modules](https://sockpuppets.medium.com/how-i-hacked-ctx-and-phpass-modules-656638c6ec5e)
 - [Twitter thread on the topic](https://twitter.com/s0md3v/status/1529005758540808192)
 - [Reddit's I think the CTX package on PyPI has been hacked!](https://www.reddit.com/r/Python/comments/uwhzkj/i_think_the_ctx_package_on_pypi_has_been_hacked/)
+<!-- markdown-link-check-disable -->
diff --git a/supply-chain-security/compromises/2022/docker-hub-malicious-containers.md b/community/catalog/compromises/2022/docker-hub-malicious-containers.md
similarity index 100%
rename from supply-chain-security/compromises/2022/docker-hub-malicious-containers.md
rename to community/catalog/compromises/2022/docker-hub-malicious-containers.md
diff --git a/supply-chain-security/compromises/2022/dropbox-github-account-breach.md b/community/catalog/compromises/2022/dropbox-github-account-breach.md
similarity index 100%
rename from supply-chain-security/compromises/2022/dropbox-github-account-breach.md
rename to community/catalog/compromises/2022/dropbox-github-account-breach.md
diff --git a/supply-chain-security/compromises/2022/fantasy.md b/community/catalog/compromises/2022/fantasy.md
similarity index 100%
rename from supply-chain-security/compromises/2022/fantasy.md
rename to community/catalog/compromises/2022/fantasy.md
diff --git a/supply-chain-security/compromises/2022/golang-buildpacks-compiler.md b/community/catalog/compromises/2022/golang-buildpacks-compiler.md
similarity index 100%
rename from supply-chain-security/compromises/2022/golang-buildpacks-compiler.md
rename to community/catalog/compromises/2022/golang-buildpacks-compiler.md
diff --git a/supply-chain-security/compromises/2022/intel-alder-lake-BIOS-leak.md b/community/catalog/compromises/2022/intel-alder-lake-BIOS-leak.md
similarity index 100%
rename from supply-chain-security/compromises/2022/intel-alder-lake-BIOS-leak.md
rename to community/catalog/compromises/2022/intel-alder-lake-BIOS-leak.md
diff --git a/supply-chain-security/compromises/2022/js-faker-colors.md b/community/catalog/compromises/2022/js-faker-colors.md
similarity index 100%
rename from supply-chain-security/compromises/2022/js-faker-colors.md
rename to community/catalog/compromises/2022/js-faker-colors.md
diff --git a/supply-chain-security/compromises/2022/node-ipc-peacenotwar.md b/community/catalog/compromises/2022/node-ipc-peacenotwar.md
similarity index 100%
rename from supply-chain-security/compromises/2022/node-ipc-peacenotwar.md
rename to community/catalog/compromises/2022/node-ipc-peacenotwar.md
diff --git a/supply-chain-security/compromises/2022/okta-github-repo-leak.md b/community/catalog/compromises/2022/okta-github-repo-leak.md
similarity index 100%
rename from supply-chain-security/compromises/2022/okta-github-repo-leak.md
rename to community/catalog/compromises/2022/okta-github-repo-leak.md
diff --git a/supply-chain-security/compromises/2022/php-pear-compromise.md b/community/catalog/compromises/2022/php-pear-compromise.md
similarity index 100%
rename from supply-chain-security/compromises/2022/php-pear-compromise.md
rename to community/catalog/compromises/2022/php-pear-compromise.md
diff --git a/supply-chain-security/compromises/2022/pypi-malicious-packages.md b/community/catalog/compromises/2022/pypi-malicious-packages.md
similarity index 100%
rename from supply-chain-security/compromises/2022/pypi-malicious-packages.md
rename to community/catalog/compromises/2022/pypi-malicious-packages.md
diff --git a/supply-chain-security/compromises/2022/ruby-override.md b/community/catalog/compromises/2022/ruby-override.md
similarity index 100%
rename from supply-chain-security/compromises/2022/ruby-override.md
rename to community/catalog/compromises/2022/ruby-override.md
diff --git a/supply-chain-security/compromises/2022/wp-apthemes.md b/community/catalog/compromises/2022/wp-apthemes.md
similarity index 100%
rename from supply-chain-security/compromises/2022/wp-apthemes.md
rename to community/catalog/compromises/2022/wp-apthemes.md
diff --git a/supply-chain-security/compromises/2023/fake-dependabot.md b/community/catalog/compromises/2023/fake-dependabot.md
similarity index 100%
rename from supply-chain-security/compromises/2023/fake-dependabot.md
rename to community/catalog/compromises/2023/fake-dependabot.md
diff --git a/supply-chain-security/compromises/2023/mathjs-min.md b/community/catalog/compromises/2023/mathjs-min.md
similarity index 100%
rename from supply-chain-security/compromises/2023/mathjs-min.md
rename to community/catalog/compromises/2023/mathjs-min.md
diff --git a/supply-chain-security/compromises/2023/packagist-maintainer-takeover.md b/community/catalog/compromises/2023/packagist-maintainer-takeover.md
similarity index 100%
rename from supply-chain-security/compromises/2023/packagist-maintainer-takeover.md
rename to community/catalog/compromises/2023/packagist-maintainer-takeover.md
diff --git a/supply-chain-security/compromises/2023/retool-portal-mfa.md b/community/catalog/compromises/2023/retool-portal-mfa.md
similarity index 100%
rename from supply-chain-security/compromises/2023/retool-portal-mfa.md
rename to community/catalog/compromises/2023/retool-portal-mfa.md
diff --git a/supply-chain-security/compromises/2023/xmlsec-manageengine.md b/community/catalog/compromises/2023/xmlsec-manageengine.md
similarity index 100%
rename from supply-chain-security/compromises/2023/xmlsec-manageengine.md
rename to community/catalog/compromises/2023/xmlsec-manageengine.md
diff --git a/supply-chain-security/compromises/2024/gitgot.md b/community/catalog/compromises/2024/gitgot.md
similarity index 100%
rename from supply-chain-security/compromises/2024/gitgot.md
rename to community/catalog/compromises/2024/gitgot.md
diff --git a/supply-chain-security/compromises/2024/laixi-3proxy.md b/community/catalog/compromises/2024/laixi-3proxy.md
similarity index 100%
rename from supply-chain-security/compromises/2024/laixi-3proxy.md
rename to community/catalog/compromises/2024/laixi-3proxy.md
diff --git a/community/catalog/compromises/2024/polyfill.md b/community/catalog/compromises/2024/polyfill.md
new file mode 100644
index 000000000..9bfaf0b60
--- /dev/null
+++ b/community/catalog/compromises/2024/polyfill.md
@@ -0,0 +1,26 @@
+<!-- cSpell:ignore fastly staticfile namecheap sansec polyfillpolyfill -->
+# Polyfill.io Infrastructure Takeover Leading to Malware Distribution
+
+In February 2024, a Chinese company acquired control of the `polyfill dot io,com` domains, and the `polyfillpolyfill` GitHub account.
+
+In June 2024, Sansec observed malware being served from the `cdn dot polyfill dot io` domain. Other researchers discovered some of the malware's functions referenced in other domains including BootCSS, BootCDN and Staticfile, and based on exposed API keys in public GitHub repositories, proposed the same threat actor is behind all the domains.
+
+## Impact
+
+* While the observed malware only performed site redirection, malicious control of `cdn dot polyfill dot io` could result in arbitrary malicious JavaScript code execution in users' browsers.
+* Namecheap shut down the domain for a period of time, and some threat feeds flagged the domain as malicious
+* While polyfills shouldn't be required in modern browsers, and despite the project's creator warning users since February to steer away from the `polyfill dot io` domain, this incident prompted Fastly and Cloudflare to offer safer drop-in replacements
+* Google Ads started disapproving ads pointing to sites using the affected domains
+* Sansec estimated this incident affects over 100,000 websites, and Cloudflare's CEO said about 4% of the web used `polyfill dot io`
+
+## Type of Compromise
+
+This is a _publishing infrastructure_ compromise.
+
+## References
+
+* [Sansec Research](https://sansec.io/research/polyfill-supply-chain-attack)
+* [BleepingComputer](https://www.bleepingcomputer.com/news/security/polyfillio-bootcdn-bootcss-staticfile-attack-traced-to-1-operator/)
+* [BleepingComputer](https://www.bleepingcomputer.com/news/security/polyfill-claims-it-has-been-defamed-returns-after-domain-shut-down/)
+* [Fastly Community](https://community.fastly.com/t/new-options-for-polyfill-io-users/2540)
+* [Cloudflare Blog](https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/)
diff --git a/supply-chain-security/compromises/2024/targeted-signed-endoor.md b/community/catalog/compromises/2024/targeted-signed-endoor.md
similarity index 100%
rename from supply-chain-security/compromises/2024/targeted-signed-endoor.md
rename to community/catalog/compromises/2024/targeted-signed-endoor.md
diff --git a/supply-chain-security/compromises/2024/xz.md b/community/catalog/compromises/2024/xz.md
similarity index 100%
rename from supply-chain-security/compromises/2024/xz.md
rename to community/catalog/compromises/2024/xz.md
diff --git a/supply-chain-security/compromises/README.md b/community/catalog/compromises/README.md
similarity index 97%
rename from supply-chain-security/compromises/README.md
rename to community/catalog/compromises/README.md
index 41abf6e4f..e9301b228 100644
--- a/supply-chain-security/compromises/README.md
+++ b/community/catalog/compromises/README.md
@@ -8,8 +8,7 @@ The goal is not to catalog every known supply chain attack, but rather to captur
 many examples of different kinds of attack, so that we can better understand the
 patterns and develop best practices and tools.
 
-For definitions of each compromise type, please check out our [compromise
-definitions page](/supply-chain-security/compromises/compromise-definitions.md)
+For definitions of each compromise type, please check out our [compromise definitions page](community/catalog/compromises/compromise-definitions.md)
 
 We welcome additions to this catalog by [filing an
 issue](https://github.com/cncf/tag-security/issues/new/choose) or [github pull
@@ -23,18 +22,19 @@ enforcement of one of open sources founding principles, "[Linus's
 Law](https://en.wikipedia.org/wiki/Linus%27s_law)".
 
 When submitting an addition, please review the
-[definitions](https://github.com/cncf/sig-security/blob/master/supply-chain-security/compromises/compromise-definitions.md)
+[definitions](./compromise-definitions.md)
 page to ensure the Type of Compromise on the details of the incidents as well as
 the Catalog itself are consistent. If a definition doesn't exist or a new type
 of compromise needs added, please include that as well.
 <!-- cSpell:disable -->
 | Name              | Year               | Type of compromise    | Link        |
 | ----------------- | ------------------ | ------------------    | ----------- |
+| [Polyfill.io Infrastructure Takeover Leading to Malware Distribution](2024/polyfill.md) | 2024 | Publishing Infrastructure | [1](https://sansec.io/research/polyfill-supply-chain-attack) |
 | [Malware Disguised as Installer used to target Korean Public Institution](2024/targeted-signed-endoor.md) | 2024 | Trust and Signing | [1](https://asec.ahnlab.com/en/63396/) |
 | [3proxy signing incident](2024/laixi-3proxy.md) | 2024 | Trust and Signing | [1](https://news.sophos.com/en-us/2024/04/09/smoke-and-screen-mirrors-a-strange-signed-backdoor/) |
 | [xz backdoor incident](2024/xz.md) | 2024 | Malicious Maintainer | [1](https://cloudsecurityalliance.org/blog/2024/04/25/navigating-the-xz-utils-vulnerability-cve-2024-3094-a-comprehensive-guide) |
 | [GitGot: using GitHub repositories as exfiltration store](2024/gitgot.md) | 2024 | Trust and Signing | [1](https://www.reversinglabs.com/blog/gitgot-cybercriminals-using-github-to-store-stolen-data) |
-| [ManageEngine xmlsec dependency](2023/xmlsec-manageengine.md) | 2023 | Outdated Dependencies | [1](ttps://flashpoint.io/blog/manageengine-apache-santuario-cve-2022-47966) |
+| [ManageEngine xmlsec dependency](2023/xmlsec-manageengine.md) | 2023 | Outdated Dependencies | [1](https://flashpoint.io/blog/manageengine-apache-santuario-cve-2022-47966) |
 | [Retool Spear Phishing](2023/retool-portal-mfa.md) | 2023 | Dev Tooling | [1](https://www.coindesk.com/business/2023/09/13/phishing-attack-on-cloud-provider-with-fortune-500-clients-led-to-15m-crypto-theft-from-fortress-trust/) |
 | [Fake Dependabot commits](2023/fake-dependabot.md) | 2023 | Source Code | [1](https://checkmarx.com/blog/surprise-when-dependabot-contributes-malicious-code/) |
 | [Okta Source Code Theft](2022/okta-github-repo-leak.md) | 2022 | Source Code <br> Dev Tooling | [1](https://www.bleepingcomputer.com/news/security/oktas-source-code-stolen-after-github-repositories-hacked/) |
diff --git a/supply-chain-security/compromises/compromise-definitions.md b/community/catalog/compromises/compromise-definitions.md
similarity index 100%
rename from supply-chain-security/compromises/compromise-definitions.md
rename to community/catalog/compromises/compromise-definitions.md
diff --git a/community/events/README.md b/community/events/README.md
deleted file mode 100644
index 957adec1d..000000000
--- a/community/events/README.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Events
-
-## Upcoming Gatherings
-
-[CloudNativeSecurityCon](https://events.linuxfoundation.org/cloudnativesecuritycon-north-america/):
-June 26 – 27, 2024 — Seattle, Washington
-
-## Recurring General Meetings
-
-[Weekly US Meeting](https://zoom.us/j/99809474566): each Wednesday at 10 am (UTC-7)
-
-[Bi-Weekly EMEA Meeting](https://zoom.us/j/99917523142): on Wednesdays at 1 pm (UTC+0, UTC+1 when daylight saving time is in effect)
diff --git a/community/events/cloud-native-security.md b/community/events/cloud_native_security.md
similarity index 99%
rename from community/events/cloud-native-security.md
rename to community/events/cloud_native_security.md
index 1dae9e28e..481e0c80c 100644
--- a/community/events/cloud-native-security.md
+++ b/community/events/cloud_native_security.md
@@ -23,7 +23,6 @@ project, architecture, and enhance team awareness on security.
 
 - Copenhagen, Denmark
 - May 2-4, 2018
-- [notes](safe-kubecon.md)
 
 [KubeCon + CloudNativeCon, Shanghai](https://events19.linuxfoundation.cn/events/kubecon-cloudnativecon-china-2018/)
 
diff --git a/community/events/past-events.md b/community/events/past-events.md
deleted file mode 100644
index 44e2aa593..000000000
--- a/community/events/past-events.md
+++ /dev/null
@@ -1,201 +0,0 @@
-# Past Events
-
-<!-- cSpell:ignore raycolline -->
-<!-- cSpell:ignore tsandall -->
-<!-- cSpell:ignore timothyhinrichs -->
-<!-- cSpell:ignore sreetummidi -->
-
-A list of past KubeCon/Cloud Native SecurityCon events can be found [here](cloud-native-security.md)
-
-## DockerCon, San Francisco, CA, Apr 30 - May 2, 2019
-
-[issue#151](https://github.com/cncf/tag-security/issues/151)
-
-### TAG talks
-
-- [CNCF TAG-Security Intro](https://kccnceu19.sched.com/event/OB0K/intro-cncf-security-tag-sarah-allen-jeyappragash-jeyakeerthi-tetrateio)
-\-  [slides](https://docs.google.com/presentation/d/1KE2tDDOeEOXQLF6hSrAuQLn4z25O_jeHIeAVE4CB-VI/edit#slide=id.gc6fa3c898_0_70)
-| [video](https://www.youtube.com/watch?v=XD89-v3oWPE)
-
-- [CNCF TAG-Security Deep Dive](https://kccnceu19.sched.com/event/Oscd/deep-dive-cncf-security-tag-justin-cappos-new-york-university-zhipeng-huang-huawei)
-\- [slides](https://docs.google.com/presentation/d/18nzXspPuRDRKfGUSI1ogFHmUOP_XHS78nz-0uTG9Ogs/edit?usp=sharing)
-| [video](https://www.youtube.com/watch?v=EF3nl80kpm4)
-- [Inside CNCF Project Security Reviews](https://kccnceu19.sched.com/event/MPdf/inside-the-cncf-project-security-reviews-justin-cormack-docker)
-\- [video](https://www.youtube.com/watch?v=0BkKpsrUo5k)
-
-### Misc security-related talks
-
-- [Intro: TUF/Notary](https://docs.google.com/presentation/d/1Mp4pSMEvZIv0qo6wBWm-4vM6CZ-0IXimpq8zD3iTH0Q/edit#slide=id.g5a645bebe8_0_921)
-\- [video](https://www.youtube.com/watch?v=gIFRQObHbZk)
-- [Deep Dive: TUF/Notary](https://kccnceu19.sched.com/event/MPkF/deep-dive-tuf-notary-justin-cappos-lukas-puehringer-nyu)
-\- [video](https://www.youtube.com/watch?v=PSujE86JvBk)
-- [Intro: SPIFFE](https://kccnceu19.sched.com/event/MPib/intro-spiffe-emiliano-bernbaum-scott-emmons-scytale)
-\- [video](https://www.youtube.com/watch?v=Rx6PMptyEtg)
-- [Deep Dive: SPIFFE](https://kccnceu19.sched.com/event/MPk9/deep-dive-spiffe-scott-emmons-emiliano-bernbaum-scytale)
-\- [video](https://www.youtube.com/watch?v=OHiPsqT1gcI)
-- [Intro: Open Policy Agent](https://kccnceu19.sched.com/event/MPiM/intro-open-policy-agent-rita-zhang-microsoft-max-smythe-google)
-\- [video](https://www.youtube.com/watch?v=Yup1FUc2Qn0)
-- [Deep Dive: Open Policy Agent](https://kccnceu19.sched.com/event/MPk0/deep-dive-open-policy-agent-torin-sandall-tim-hinrichs-styra)
-\- [video](https://www.youtube.com/watch?v=n94_FNhuzy4)
-- [Secrets Store CSI Driver-Bring Your Own Enterprise Secrets Store to K8s](https://kccnceu19.sched.com/event/MPdZ/secrets-store-csi-driver-bring-your-own-enterprise-secrets-store-to-k8s-rita-zhang-microsoft-anubhav-mishra-hashicorp)
-\- [video](https://www.youtube.com/watch?v=bIC4kLnrKN0)
-- [Protecting the Data Lake with OPA](https://sched.co/MPdu)
-\- [slides](https://drive.google.com/file/d/1NVKn88EoRAzi_Kd5KGPfOjd6fZpLhjJE/view?usp=sharing)
-| [video](https://www.youtube.com/watch?v=9m4FymEvOqM)
-- [Securing Kubernetes with Trusted Platform Module (TPM)](https://kccnceu19.sched.com/event/MPdN/securing-kubernetes-with-trusted-platform-module-tpm-alex-tcherniakhovski-andrew-lytvynov-google)
-\- [slides](https://static.sched.com/hosted_files/kccnceu19/a9/Securing%20Kubernetes%20with%20Trusted%20Platform%20Module.pdf)
-| [video](https://www.youtube.com/watch?v=_kxmkI8Kc8Y)
-- [Uber x Security: Why and How We Built Our Workload Identity Platform](https://kccnceu19.sched.com/event/MPe6)
-\- [slides](https://static.sched.com/hosted_files/kccnceu19/bf/slides-julian-feldman.pdf)
-| [video](https://www.youtube.com/watch?v=JKkq60DvPBw)
-
-## Past Meetings
-<!-- markdownlint-disable-next-line -->
-<details><summary>Click to view list</summary>
-
-* [2019-09-25 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-09-18 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-09-11 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-09-04 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-08-28 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-08-21 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-08-14 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-08-07 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-07-31 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-07-24 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-07-17 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-07-10 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-07-03 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-06-26 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-06-19 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-06-12 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-06-05 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-05-29 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* 2019-05-22 CNCF TAG-Security Meeting - No Meeting due to KubeCon Europe
-* [2019-05-15 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-\- OPA with SAFE Presentation Framework
-* [2019-05-08 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit)
-* [2019-04-12 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-04-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-04-05 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Google Open Source Project Onboarding
-* [2019-04-04 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-03-29 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Revised presentation framework with in-toto (OPA, Kamus, TOC invited)
-* [2019-03-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- SAFE Whitepaper Working Session
-* [2019-03-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-03-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-03-07 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-03-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-02-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-02-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-02-21 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-02-15 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-02-08 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-02-01 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-01-31 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-01-25 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-01-24 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-01-18 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-01-17 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session
-* [2019-01-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2019-01-10 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-\- Working Session - :star: [new meeting notes doc](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit)
-* [2018-12-21 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-12-13 SAFE WG BOF Deep Dive @ KubeCon + CloudNativeCon North America 2018](https://kccna18.sched.com/event/GrdR/deep-dive-safe-bof-jeyappragash-jeyakeerthi-padmeio-dan-shaw-danshaw-llc)
-* 2018-12-11 SAFE WG Dinner @ KubeCon + CloudNativeCon North America 2018
-* [2018-12-11 SAFE WG BOF Intro @ KubeCon + CloudNativeCon North America
-2018](https://kccna18.sched.com/event/GrbV/intro-safe-bof-jeyappragash-jeyakeerthi-padmeio-dan-shaw-danshaw-llc)
-* [2018-12-14 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-12-07 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-11-30 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-11-29 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* 2018-11-23 - no meeting
-* 2018-11-22 - no meeting :turkey:
-* [2018-11-16 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-11-15 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* 2018-11-14 - KubeCon Shanghai 2018 Intro Session:
-[Intro: SAFE (A Cloud Native Security Working Group)](https://kccncchina2018english.sched.com/event/FuLG)
-* 2018-11-09 - no meeting: [SPIFFE Community Day](https://docs.google.com/document/d/1Gt91uPgemRuW56P3qnuQfs0VoWn_2n0D8N-LxpnUu5c/edit)
-* [2018-11-08 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-10-26 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-10-25 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-10-19 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-10-12 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-10-05 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-10-04 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-09-28 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-09-21 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-09-20 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-09-14 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-09-07 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-09-06 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-08-31 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-31 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-30 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-24 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* 2018-08-21 SAFE WG proposal to the CNCF TOC
-* [2018-08-17 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-16 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-08-10 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-09 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-08-03 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-* [2018-08-02 SAFE Meeting](https://docs.google.com/document/d/1JsEv4vk_61UaF9SaHBRzzPGja-bNsHeLqxa53RPVfos/edit)
-\- Working Session
-* [2018-07-27 SAFE Meeting](https://docs.google.com/document/d/1DqqeTguBpalPj-y4nqY0uo8vYn_tU6DJzmbIdoyslhw/edit)
-* [2018-07-13 SAFE Meeting](https://docs.google.com/document/d/1sniqXFFcP4vpX2bO6NeB31mzO1YOJrcQy2ryXATSHmk/edit)
-* [2018-06-29 SAFE Meeting](https://docs.google.com/document/d/1fyBDIm82xtTYWhZu3gyLahltMdTOxl9aWfOfRxYHapo/edit)
-* [2018-06-15 SAFE Meeting](https://docs.google.com/document/d/1usB6Xw1GVjW--RkRw1RPypwvUP_E8trtzg9JTO1ZAkM/edit)
-* [2018-06-08 SAFE Meeting](https://docs.google.com/document/d/10iJ3wA7uVI6JMyvIv9qXdxdLCyQeS-djYsTqL_JG3d0/edit)
-* 2018-06-01 - no meeting
-* [2018-05-25 SAFE Meeting](https://docs.google.com/document/d/1LEXzz1PUaboqyIBg-1QBj-R0T1z6950fsetkBEW7b8g/edit)
-* [2018-05-18 SAFE Meeting](https://docs.google.com/document/d/1xzJ29fTOJSioqrDuSkvBfsewV2lvgbr8olmDWb4kdPk/edit)
-* [2018-05-11 SAFE Meeting](https://docs.google.com/document/d/1U5SKjp4vvN_I1CEw-O0mf7yhjhLzpRnTsaCxQS3CdIQ/edit)
-* KubeCon Europe 2018 Deep-dive Session
-* KubeCon Europe 2018 Intro Session
-* [2018-04-27 SAFE Meeting](https://docs.google.com/document/d/1mtdBg6-8eGgBCfIFT56dDe_LVRCw5_tSeIAsRH_8KfM/edit)
-* [2018-04-20 SAFE Meeting](https://docs.google.com/document/d/1B7G0_V1i8DTX-JIzMquUzFJgJBzZN-NWkJDCi62LOh4/edit)
-\- CNCF TOC Proposal follow-up
-* [2018-04-13 SAFE Meeting](https://docs.google.com/document/d/1SVPJzQrEpBixugI1Kjww90RxhaOovdNhWtWb3LsSjYU/edit)
-\- Prep for the SAFE WG proposal presentation to the CNCF TOC on 4/17
-* [2018-04-06 SAFE Meeting](https://docs.google.com/document/d/1a_a0dUTdSERgHiAnbUL0r2PNvbTe0SWHmYh7yFhTiFk/edit)
-\- SAFE Personas WhitePaper
-* [2018-03-30 SAFE Meeting](https://docs.google.com/document/d/1KwqAlBpb8TAex4_ABFmxpPZq9-MPvK3kraLUW9ws1EE/edit)
-* [2018-03-23 SAFE Meeting](https://docs.google.com/document/d/1H3VOI9-GqRAj_tdPL9sECF1c8t4x_sF1G08PqLzlUWM/edit)
-\- NIST Big Data public working group - security and privacy subgroup with Mark Underwood
-* [2018-03-16 SAFE Meeting](https://docs.google.com/document/d/1nYN3cy7jrKQbEziT43447w8ZValOuioxEKYE0D4vkPU/edit)
-* 2018-03-09 - no meeting
-* [2018-03-02 SAFE Meeting](https://docs.google.com/document/d/1vZfDHLh2jy0uH_U_qLpbp64Xy64gu0SrgVLJov4kuMw/edit)
-\- GCP Administrators Bill of Rights with @raycolline
-* [2018-02-23 SAFE Meeting](https://docs.google.com/document/d/1U4x1wynL-JlojF1Qidus97t8bJve3XJWTpc07hHCAxU/edit)
-\- Open Policy Agent (OPA) Use Case with [@tsandall](https://github.com/tsandall)
-and [@timothyhinrichs](https://github.com/timothyhinrichs)
-* [2018-02-16 SAFE Meeting](https://docs.google.com/document/d/1aAldFgdU6EhtmQWCFMefFMaevKumDe08wMlfoCt9mFw/edit)
-\- Cloud Foundry Use Case with [@sreetummidi](https://github.com/sreetummidi)
-* [2018-02-07 SAFE Meeting](https://docs.google.com/document/d/1Z30hfVquiRz9dIjek0Tcg540LuX3D4TPhJ3UWpDMltU/edit)
-
-</details>
diff --git a/community/events/safe-kubecon.md b/community/events/safe-kubecon.md
deleted file mode 100644
index 37a433a7f..000000000
--- a/community/events/safe-kubecon.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# SAFE Recap @ [Kubecon Europe 2018](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/)
-
-SAFE had two sessions for introducing SAFE and  getting feedback from the community.
-
-* [SAFE WG Intro](https://kccnceu18.sched.com/event/ENw3/safe-wg-intro-jeyappragash-j-j-padmeio-ray-colline-google-any-skill-level)
-* [SAFE WG Deep Dive](https://kccnceu18.sched.com/event/ENw5/safe-wg-deep-dive-ray-colline-google-intermediate-skill-level)
-
-We had a small but relevant group and hallway conversations were equally engaging and informative.
-
-Excited to have [Liz Rice](https://github.com/lizrice) and [Justin Cormack](https://github.com/justincormack) join us.
-
-Across the board, everyone I had conversation with, there was a natural acknowledgement that security is an end-end problem and understanding secure access and providing a safe end-end system for end-user is critical. Highlighted at the [keynote by Alexis](https://twitter.com/MayaKaczorowski/status/991601395450171392?s=15).
-
-We are just getting started on this, incredibly excited to be part of this team and the effort!
diff --git a/publications/README.md b/community/publications/README.md
similarity index 78%
rename from publications/README.md
rename to community/publications/README.md
index c2dc977c3..e6af8db25 100644
--- a/publications/README.md
+++ b/community/publications/README.md
@@ -13,20 +13,20 @@ This document lists all the publications and resources that TAG Security has pro
 | | **Translations** | | |
 | | | Portuguese (v1) | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md) |
 | | | Chinese (v1) | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md) |
-| **Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security** | Guide for assessing and understanding the security of open source software projects | PDF | [Link](https://github.com/cncf/tag-security/blob/main/assessments/Open_and_Secure.pdf) |
+| **Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security** | Guide for assessing and understanding the security of open source software projects | PDF | [Link](/community/assessments/Open_and_Secure.pdf) |
 | **Policy** | | | |
 | | Formal Verification for Policy Configurations | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-formal-verification.md) |
 | | Handling build-time dependency vulnerabilities | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/policy/overview-policy-build-time-dependency-vulns.md) |
 | **Secure Defaults: Cloud Native 8** | | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/security-whitepaper/secure-defaults-cloud-native-8.md) |
 | **Security Assessments** | Assessments of several CNCF projects | | |
-| | Buildpacks | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/buildpacks) |
-| | Cloud Custodian | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/custodian) |
-| | Harbor | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/harbor) |
-| | In-toto | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/in-toto) |
-| | Keycloak | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/keycloak) |
-| | Kyverno | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/kyverno) |
-| | OPA | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/opa) |
-| | Spiffe-Spire | Markdown | [Link](https://github.com/cncf/tag-security/tree/main/assessments/projects/spiffe-spire) |
+| | Buildpacks | Markdown | [Link](/community/assessments/projects/buildpacks) |
+| | Cloud Custodian | Markdown | [Link](/community/assessments/projects/custodian) |
+| | Harbor | Markdown | [Link](/community/assessments/projects/harbor) |
+| | In-toto | Markdown | [Link](/community/assessments/projects/in-toto) |
+| | Keycloak | Markdown | [Link](/community/assessments/projects/keycloak) |
+| | Kyverno | Markdown | [Link](/community/assessments/projects/kyverno) |
+| | OPA | Markdown | [Link](/community/assessments/projects/opa) |
+| | Spiffe-Spire | Markdown | [Link](/community/assessments/projects/spiffe-spire) |
 | **Supply Chain Security** | | | |
 | | Software Supply Chain Best Practices | Markdown | [Link](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md) |
 | | | PDF | [Link](https://github.com/cncf/tag-security/raw/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) |
diff --git a/audio-versions/README.md b/community/publications/audio-versions/README.md
similarity index 100%
rename from audio-versions/README.md
rename to community/publications/audio-versions/README.md
diff --git a/publications/authoring-guidelines.md b/community/publications/authoring-guidelines.md
similarity index 100%
rename from publications/authoring-guidelines.md
rename to community/publications/authoring-guidelines.md
diff --git a/publications/paper-process.md b/community/publications/paper-process.md
similarity index 100%
rename from publications/paper-process.md
rename to community/publications/paper-process.md
diff --git a/publications/publishing-protocols.md b/community/publications/publishing-protocols.md
similarity index 100%
rename from publications/publishing-protocols.md
rename to community/publications/publishing-protocols.md
diff --git a/design/README.md b/community/resources/design/README.md
similarity index 100%
rename from design/README.md
rename to community/resources/design/README.md
diff --git a/design/colors/#141419.png b/community/resources/design/colors/#141419.png
similarity index 100%
rename from design/colors/#141419.png
rename to community/resources/design/colors/#141419.png
diff --git a/design/colors/#152356.png b/community/resources/design/colors/#152356.png
similarity index 100%
rename from design/colors/#152356.png
rename to community/resources/design/colors/#152356.png
diff --git a/design/colors/#389BB2.png b/community/resources/design/colors/#389BB2.png
similarity index 100%
rename from design/colors/#389BB2.png
rename to community/resources/design/colors/#389BB2.png
diff --git a/design/colors/#474756.png b/community/resources/design/colors/#474756.png
similarity index 100%
rename from design/colors/#474756.png
rename to community/resources/design/colors/#474756.png
diff --git a/design/colors/#4A6CA4.png b/community/resources/design/colors/#4A6CA4.png
similarity index 100%
rename from design/colors/#4A6CA4.png
rename to community/resources/design/colors/#4A6CA4.png
diff --git a/design/colors/#6F6F7F.png b/community/resources/design/colors/#6F6F7F.png
similarity index 100%
rename from design/colors/#6F6F7F.png
rename to community/resources/design/colors/#6F6F7F.png
diff --git a/design/colors/#85C2D2.png b/community/resources/design/colors/#85C2D2.png
similarity index 100%
rename from design/colors/#85C2D2.png
rename to community/resources/design/colors/#85C2D2.png
diff --git a/design/colors/#D81637.png b/community/resources/design/colors/#D81637.png
similarity index 100%
rename from design/colors/#D81637.png
rename to community/resources/design/colors/#D81637.png
diff --git a/design/colors/#F7C906.png b/community/resources/design/colors/#F7C906.png
similarity index 100%
rename from design/colors/#F7C906.png
rename to community/resources/design/colors/#F7C906.png
diff --git a/design/colors/#F98903.png b/community/resources/design/colors/#F98903.png
similarity index 100%
rename from design/colors/#F98903.png
rename to community/resources/design/colors/#F98903.png
diff --git a/design/logo/cloud-native-security-horizontal-color.png b/community/resources/design/logo/cloud-native-security-horizontal-color.png
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-color.png
rename to community/resources/design/logo/cloud-native-security-horizontal-color.png
diff --git a/design/logo/cloud-native-security-horizontal-color.svg b/community/resources/design/logo/cloud-native-security-horizontal-color.svg
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-color.svg
rename to community/resources/design/logo/cloud-native-security-horizontal-color.svg
diff --git a/design/logo/cloud-native-security-horizontal-darkmodesafe.png b/community/resources/design/logo/cloud-native-security-horizontal-darkmodesafe.png
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-darkmodesafe.png
rename to community/resources/design/logo/cloud-native-security-horizontal-darkmodesafe.png
diff --git a/design/logo/cloud-native-security-horizontal-darkmodesafe.svg b/community/resources/design/logo/cloud-native-security-horizontal-darkmodesafe.svg
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-darkmodesafe.svg
rename to community/resources/design/logo/cloud-native-security-horizontal-darkmodesafe.svg
diff --git a/design/logo/cloud-native-security-horizontal-white-display.png b/community/resources/design/logo/cloud-native-security-horizontal-white-display.png
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-white-display.png
rename to community/resources/design/logo/cloud-native-security-horizontal-white-display.png
diff --git a/design/logo/cloud-native-security-horizontal-white.png b/community/resources/design/logo/cloud-native-security-horizontal-white.png
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-white.png
rename to community/resources/design/logo/cloud-native-security-horizontal-white.png
diff --git a/design/logo/cloud-native-security-horizontal-white.svg b/community/resources/design/logo/cloud-native-security-horizontal-white.svg
similarity index 100%
rename from design/logo/cloud-native-security-horizontal-white.svg
rename to community/resources/design/logo/cloud-native-security-horizontal-white.svg
diff --git a/design/logo/cloud-native-security-icon-color.png b/community/resources/design/logo/cloud-native-security-icon-color.png
similarity index 100%
rename from design/logo/cloud-native-security-icon-color.png
rename to community/resources/design/logo/cloud-native-security-icon-color.png
diff --git a/design/logo/cloud-native-security-icon-color.svg b/community/resources/design/logo/cloud-native-security-icon-color.svg
similarity index 100%
rename from design/logo/cloud-native-security-icon-color.svg
rename to community/resources/design/logo/cloud-native-security-icon-color.svg
diff --git a/design/logo/cloud-native-security-icon-white-display.png b/community/resources/design/logo/cloud-native-security-icon-white-display.png
similarity index 100%
rename from design/logo/cloud-native-security-icon-white-display.png
rename to community/resources/design/logo/cloud-native-security-icon-white-display.png
diff --git a/design/logo/cloud-native-security-icon-white.png b/community/resources/design/logo/cloud-native-security-icon-white.png
similarity index 100%
rename from design/logo/cloud-native-security-icon-white.png
rename to community/resources/design/logo/cloud-native-security-icon-white.png
diff --git a/design/logo/cloud-native-security-icon-white.svg b/community/resources/design/logo/cloud-native-security-icon-white.svg
similarity index 100%
rename from design/logo/cloud-native-security-icon-white.svg
rename to community/resources/design/logo/cloud-native-security-icon-white.svg
diff --git a/design/logo/cloud-native-security-stacked-color.png b/community/resources/design/logo/cloud-native-security-stacked-color.png
similarity index 100%
rename from design/logo/cloud-native-security-stacked-color.png
rename to community/resources/design/logo/cloud-native-security-stacked-color.png
diff --git a/design/logo/cloud-native-security-stacked-color.svg b/community/resources/design/logo/cloud-native-security-stacked-color.svg
similarity index 100%
rename from design/logo/cloud-native-security-stacked-color.svg
rename to community/resources/design/logo/cloud-native-security-stacked-color.svg
diff --git a/design/logo/cloud-native-security-stacked-white-display.png b/community/resources/design/logo/cloud-native-security-stacked-white-display.png
similarity index 100%
rename from design/logo/cloud-native-security-stacked-white-display.png
rename to community/resources/design/logo/cloud-native-security-stacked-white-display.png
diff --git a/design/logo/cloud-native-security-stacked-white.png b/community/resources/design/logo/cloud-native-security-stacked-white.png
similarity index 100%
rename from design/logo/cloud-native-security-stacked-white.png
rename to community/resources/design/logo/cloud-native-security-stacked-white.png
diff --git a/design/logo/cloud-native-security-stacked-white.svg b/community/resources/design/logo/cloud-native-security-stacked-white.svg
similarity index 100%
rename from design/logo/cloud-native-security-stacked-white.svg
rename to community/resources/design/logo/cloud-native-security-stacked-white.svg
diff --git a/landscape/README.md b/community/resources/landscape/README.md
similarity index 82%
rename from landscape/README.md
rename to community/resources/landscape/README.md
index 642f9b9fb..ac6e051d3 100644
--- a/landscape/README.md
+++ b/community/resources/landscape/README.md
@@ -1,9 +1,9 @@
 ## Goal
 
-The [SAFE roadmap](../roadmap.md) includes describing the landscape of
-cloud-native security. We evaluated categories in the
+TAG Security evaluated categories in the
 [CNCF Landscape](https://landscape.cncf.io/) and
-determined the need for a [modified approach](approach.md).
+determined the need for a [modified approach](approach.md) to describe
+the landscape of cloud native security.
 
 We propose [categories](categories.md) as a draft structure for a “Cloud Native
 Security Landscape”. We drafted this document after reviewing the current list
diff --git a/landscape/approach.md b/community/resources/landscape/approach.md
similarity index 100%
rename from landscape/approach.md
rename to community/resources/landscape/approach.md
diff --git a/landscape/categories.md b/community/resources/landscape/categories.md
similarity index 100%
rename from landscape/categories.md
rename to community/resources/landscape/categories.md
diff --git a/project-resources/README.md b/community/resources/project-resources/README.md
similarity index 98%
rename from project-resources/README.md
rename to community/resources/project-resources/README.md
index 181fd7ac3..a2a07be77 100644
--- a/project-resources/README.md
+++ b/community/resources/project-resources/README.md
@@ -3,7 +3,7 @@
 This directory is intended to provide CNCF and other open source projects with
 resources and templates to assist in kick-starting their security practices.
 The templates, guides, and other documents herein assist projects in completion
-of the [self-assessment](../assessments/guide/self-assessment.md) as well as a few
+of the [self-assessment](./community/assessments/guide/self-assessment.md) as well as a few
 items in the [CII badging](https://bestpractices.coreinfrastructure.org/en)
 process.
 
diff --git a/community/resources/project-resources/SecurityGuidelines.png b/community/resources/project-resources/SecurityGuidelines.png
new file mode 100644
index 000000000..bbe8bca62
Binary files /dev/null and b/community/resources/project-resources/SecurityGuidelines.png differ
diff --git a/community/resources/project-resources/security-hygiene-guide.md b/community/resources/project-resources/security-hygiene-guide.md
new file mode 100644
index 000000000..87af35a9b
--- /dev/null
+++ b/community/resources/project-resources/security-hygiene-guide.md
@@ -0,0 +1,240 @@
+# Security Hygiene Guide for Project Maintainers
+
+> [!NOTE]
+> This guide is under revision as part of [#1260](https://github.com/cncf/tag-security/issues/1260). It's contents are accurate, but are expected to be adapted or extended.
+
+## Introduction
+
+Tackling security requirements can be a daunting task, especially in the Cloud Native landscape. There are several resources available to assist the community in their security journey, such as the resources and publications by the CNCF Technical Advisory Group for Security, OpenSSF Best Practices Working Group, and many others.
+
+Security Guidelines for New Projects aims to provide recommendations for new projects to ensure they follow the minimum measures to secure their projects and build incrementally as their maturity grows. These security guidelines can be grouped into the following categories:
+
+1. Securing code repositories
+2. Self assessment
+3. SECURITY.md
+4. Incident management
+5. Badging
+
+![](./SecurityGuidelines.png)
+
+**Figure 1**. An overview of security guidelines for new projects
+
+These guidelines are heavily influenced by the contributions of the CNCF Technical Advisory Group for Security, particularly the Cloud Native Security Whitepaper[[1]] and Software Supply Chain Security Best Practices Whitepaper[[2]] and the tooling for these guidelines can be referred to in the CNCF Cloud Native Security Map[[3]].
+
+**Note**
+
+This paper refers to GitHub as the source code management repository due to its popularity in the Open Source ecosystem, however the same guidelines are applicable to any other source code management service as well.
+
+## Goals
+
+This guide aims to outline the minimal security measures for sandbox or early maturity CNCF projects to ensure security measures are included as early as possible for the development and source code management of the project while increasing their awareness of resources to iteratively build secure practices as they enhance the maturity of the project.
+
+## 1. Securing Code Repository
+
+The foundation of a project is its source code and it is essential to ensure the integrity of the source code. Source code repositories such as GitHub allow contributions from numerous members from all across the world in a single repository which is a boon in itself, however if not leveraged securely, it can be a bane. The key to doing so is protecting the repository where the source code lies and introducing changes to the repository in a controlled and secure manner.
+
+This section outlines several measures that can be taken to ensure authorized members have access to the code repository, changes are suggested, suggested changes are reviewed, and changes are introduced to the repository in a secure and controlled manner.
+
+It should be noted that secure device management is assumed - if you have a remote access trojan on your laptop, many of these countermeasures are subverted.
+
+## 1.1 Access management
+
+### Enable Role Based Access Control (RBAC)
+
+Define roles and associated access controls based upon the different personas interacting with the code repositories. The roles should be assigned following least privilege on a need-to know basis based on their assigned responsibilities. For example, GitHub provides roles such as Owner, Maintainer, Developer, Reviewer, Approver, and Guest. Each role should then be given fine-grained permissions with regards to repository access control.
+
+### Strong Authentication mechanisms
+
+Strong authentication mechanisms are key to ensure accounts are not susceptible to several attacks including but not limited to account takeover. We highly recommend the use of password-protected SSH keys or a personal access token (PAT).
+
+However, for certain non-code intensive projects which specifically require accommodation that cannot be made possible using recommended methods (such as access to Github.com via browser), we recommend the use of unique and complex passwords (complexity in terms of a combination of alphanumeric, special characters as well as length). For details regarding configuring an authentication mechanism for GitHub, please refer to GitHub's documentation [GitHub Docs - About authentication to GitHub](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github).
+
+### Two Factor Authentication/Multi-factor Authentication
+
+Introducing an additional factor such as "something you have" or "somewhere you are" in the authentication process proves to be of higher effectiveness than relying on one factor "something you know" such as passwords. It is required to configure two factor or multi-factor authentication for your accounts, especially for any privileged accounts. For details regarding configuring a 2FA for GitHub, please refer to GitHub's documentation [GitHub Docs - Securing your account with two-factor authentication (2FA)](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa).
+
+## 1.2 Branch protection
+
+Branches in a source code repository provide a constrained area to develop features without affecting the other areas of the project. There will be certain branches which ought to be protected from unintended changes which impair code integrity. This is where branch protection helps.
+
+Branch protection provides functionality that allows a policy based approach to protecting particular branches. Policies such as who can make changes to certain branches, whether push/force push are permitted, merges with/without certain checks are permitted, whether delete operations are permitted and so on should be reviewed and configured based on the requirements of the project. For details regarding configuring protected branches for GitHub, please refer to GitHub's documentation [GitHub Docs - About protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches).
+
+We recommend that any change to the repository should be introduced as part of a pull request and should go through a review process prior to merging. At least two individuals, of which one should have write access to the branch (preferably maintainers), and both of whom are independent of the request must review and approve the request and then the change is to be merged to the project. For projects with small teams where requiring two reviewers is not feasible, it is sufficient to require only a single reviewer. For projects that have a large codebase, the implementation of Code Owners (e.g. via GitHub CODEOWNERS file) is recommended to automatically request reviews to maintainers that are responsible for specific sub-modules or features. For details regarding pull request reviews for GitHub, please refer to GitHub's documentation [GitHub Docs - About pull request reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews)
+
+## 1.3 Managing Contributions
+
+### Issue template
+
+Any ideas, bugs or enhancement suggestions reported to the project need to be tracked, and can then be discussed, triaged and prioritized/de-prioritized for implementation. GitHub Issues are one such avenue that allows tracking and managing ideas until they are brought to fruition. We recommend the following template for proposing changes to the project [CNCF TAG Security Project Resources - Issue Template](/project-resources/templates/ISSUE_TEMPLATE.md).
+
+### Commit signing
+
+Any code committed to the source code repository associated with the project is recommended to be signed to help ensure the integrity of the code and establish identity of the author(s). Git inspired SCMs like [Github](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits), [Gitlab](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/), and [Bitbucket](https://confluence.atlassian.com/bitbucketserver/using-gpg-keys-913477014.html) all provide different mechanisms to sign & enforce git commits.
+
+As the security maturity increases, it is a recommended security practice to store the private signing keys on a hardware token (HSMs or YubiKeys) and the adoption of secure key distribution method(s) is encouraged.
+
+### Secret scanning (recommended)
+
+It is critical to ensure no sensitive information is exposed as part of the source code, the documentation or any configuration in the source code repository. It may sometimes accidentally escape even the vigilant eyes of the contributor and reviewers, hence we recommend automating this activity and implementing secret scanning as part of the continuous integration process in the source code repository.
+
+There are several tools and projects aimed at providing secret scanning services, including but not limited to the ones mentioned in the section "Develop" of the Cloud Native Security Map[[3]]. GitHub also provides its own secret scanning service, you can find more details of this service at [GitHub Docs - Keeping secrets secure with secret scanning](https://docs.github.com/en/code-security/secret-scanning)
+
+### Code scanning (recommended)
+
+Code scanning is an automated security test to identify vulnerabilities and errors in the source code without actually compiling or executing the code. This is a key testing strategy to shift security testing left and we recommend configuring code scanning and utilizing its insights in your projects. There are several tools (both commercial and open source) available to perform the code scanning or an array of languages and technologies. GitHub also provides code scanning functionalities, which can be seen in their documentation - [GitHub Docs - Automatically scanning your code for vulnerabilities and errors](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors).
+
+In addition to scanning your code for identifying vulnerabilities and errors, managing the vulnerabilities dependencies is also important. [Dependabot](https://github.com/dependabot) is one tool that helps in managing vulnerabilities in dependencies by automatically raising a pull request to update vulnerable versions to secure versions of that dependency. These pull requests can be then analyzed, and further action can be taken. Further details of Dependabot and configuring it in your project code repository can be found at [GitHub Docs - Automatically updating dependencies with known vulnerabilities with Dependabot security updates](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates).
+
+For further information on securing the code repository, we recommend reviewing the **GitOps section** of the [CNCF Cloud Native Security Whitepaper](/security-whitepaper/v2/cloud-native-security-whitepaper.md#gitopsnew-in-v2) and the **Control Environments** sections of the [CNCF Software Supply Chain Best Practices paper](/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)
+
+## 2. Self-assessment
+
+CNCF Technical Advisory Group for Security states that the self-assessment is the initial document for projects to begin thinking about the security of their project, determining gaps in their security, and preparing any security documentation for their users.
+
+A security self-assessment is a great start for a new project to think ahead about the security measures that are important for the project, and also to understand the gaps in the current implementation in a proactive manner, and plan for mitigating them.
+
+Self-assessment dives into the following aspects of the project to understand the current maturity and the gaps in security implementation or the documentation aspects.
+
+1. Background and overview of the project
+2. Project architecture
+3. Project metadata
+4. Goals and Non-goals
+5. Actors and Actions
+6. Compliance and Regulatory requirements
+7. Secure development practices
+8. Resolving security issues
+
+A template to perform the self assessment is available at [CNCF TAG Security Project Resources - Self-assessment](/community/assessments/guide/self-assessment.md). All the assessments (self-assessment and joint assessment) conducted by TAG Security can be found at TAG Security GitHub repository. As an example, self assessments are available within the dedicated project folders at [Assessments folder of the CNCF TAG Security GitHub repository](/community/assessments/projects). Further sections (SECURITY.md in particular) in this document provide some of the pointers to address the gaps and create the necessary process & documentation.
+
+## 3. SECURITY.md
+
+Awareness and processes are a big part of enforcing security in any project. A SECURITY.md file in your repository should talk about the security considerations of the project, and the efforts undertaken to ensure that there are policies and processes in place to report vulnerabilities to the project maintainers, and for project maintainers to notify the community of the status of the vulnerabilities. It should also list the dedicated personnel responsible to address these vulnerabilities in a timely manner. In GitHub, the SECURITY.md file creates a security policy, and when someone creates an issue in your repository, they will see a link to your project's security policy. Further information regarding security policy is available at [GitHub Docs - Adding a security policy to your repository](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository).
+
+CNCF Technical Advisory Group for Security maintains a number of templates to assist projects in addressing these sections, which can be found at [CNCF TAG Security GitHub repository, under Project resources folder](/project-resources). A special thank you to Google's OSS vulnerability guide folks for making the Security TAG aware of this collection of resources upon which much of this content was built on.
+
+Disclaimer: These resources are designed to be helpful to projects and organizations, they require customization and configuration by the project intending to use them. It does not prevent security issues from being found in a project, will not automatically resolve them, and does not place CNCF Security TAG as the responsible party. If changes are made to these templates, projects are not required to pull in a new update.
+
+## 3.1 Security considerations
+
+This document is an outcome of the self-assessment which articulates all the measures taken in the project to tackle the security goals of the project, including but not limited to ensuring its confidentiality, integrity and availability - as well as compliance with any laws or regulations. This may also be the place for security bulletins and to list out the known vulnerabilities and patches available to mitigate them.
+
+## 3.2 Security contacts
+
+This document states who are the personnel to reach out to in case of any security questions regarding the project, including but not limited to the triaging and handling of incoming security issues or security reports. Security contacts could be external participants and are not limited to being the maintainers of the projects. A template for this document is available at [CNCF TAG Security Project resources - Security Contacts](/project-resources/templates/SECURITY_CONTACTS.md)
+
+**NOTE**
+
+CNCF could help create a mailing address (through service desk ticket) should projects need one to assist with managing their security reporting or reporting.
+
+## 3.3 Report vulnerabilities
+
+Vulnerabilities are sensitive information and exposure of information regarding vulnerabilities without the availability of a patch generates unintended risk for all the consumers of this project, hence it should be handled with caution.
+
+At a minimum, the vulnerability reporting policy projects should include is as follows, A template for this document is available at [CNCF TAG Security Project resources - Reporting a Vulnerability](/project-resources/templates/SECURITY.md#reporting-a-vulnerability):
+
+1. The medium to report vulnerabilities - Email, Web form etc.
+2. Disclosure timeline
+3. Point of contact or mailbox (if any)
+4. Bug bounty programs (if any)
+
+In addition to the vulnerability reporting policy, the defined process or co-ordinate the disclosure in a secure manner is highly recommended. There are several methods to accomplish this including encrypting vulnerability reports with GPG keys among others, and projects could leverage them based on their need.
+
+GitHub provides an easy to use, established platform to coordinate the vulnerability disclosure between the maintainers and the reporter in a private manner. Further information on the coordinated disclosure of security vulnerabilities in Github is available at [GitHub Docs - About coordinated disclosure of security vulnerabilities](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/about-coordinated-disclosure-of-security-vulnerabilities).
+
+## 3.4 Embargo Policy
+
+The vulnerabilities reported to the project are then handled by the security point of contact(s) and the rest of the stakeholders of the project. It is important to define a policy the stakeholders need to abide by in order to restrict the unauthorized disclosure of vulnerabilities. An Embargo policy is created for this purpose and at a minimum it should include:
+
+1. The stakeholders - security contacts, project maintainers and any others
+2. What is covered under this policy
+3. What is unacceptable or acceptable behavior
+4. Medium to report violations of the policy (accidental or otherwise)
+5. The consequences of any violations
+6. Disclosure timeline
+
+A template for this document is available at [CNCF TAG Security Project resources - Embargo Policy](/project-resources/templates/embargo-policy.md)
+
+## 3.5 Security notifications
+
+The vulnerabilities may need to be reported to certain stakeholders, and for this purpose, an embargo notification template can be utilized. The embargo notification at the minimum should include the information stated below:
+
+1. Purpose of the notification
+2. Summary of the notification
+3. Vulnerability name along with Common Vulnerability Enumeration (CVE), if any
+4. Affected versions of the project
+5. Severity of the vulnerability
+6. Proof of Concept
+7. Mitigation or Remediation for the vulnerability along with the fixed versions
+8. Timeline of events associated with this notification
+9. Any additional information relevant for this notification
+
+A template for this notification is available at [CNCF TAG Security Project resources - Embargo](/project-resources/templates/embargo.md)
+
+## 4. Incident Response
+
+Incident response defines the processes that aid in solving a security issue. This issue may be an internal finding or one that was reported by an external party, in which case it includes the processes between the vulnerability reporting and embargo notification.
+
+Incidence response primarily states how the vulnerability is triaged, replicated, and notified. The incident response process should include the following at a minimum:
+
+1. Identification of the security issue or an incident
+  1. What are the affected components?
+  2. What type of an issue is it?
+  3. How complex is this issue?
+  4. How severe is the impact?
+  5. What use of interaction and privilege is needed?
+  6. Is there an exploit available?
+2. Acknowledge the receipt of this problem
+3. How can the issue be reproduced or replicated?
+  1. If a CVE is already present, request the CVE
+4. Patch publication and Notification
+
+In addition to the above, you could also consider adding relevant timelines, including but not limited to third party disclosure timelines. A template for the incident management process is available at [CNCF TAG Security Project resources - Incident Response](/project-resources/templates/incident-response.md)
+
+## 5. OpenSSF best practices badging
+
+The [Open Source Security Foundation (OpenSSF)](https://openssf.org/) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices[[5]]. This initiative allows projects to voluntarily self-certify, at no cost, by using their web application[[5]] to explain how they follow each best practice. These badges are a great way to showcase the efforts towards securing the project.
+
+The criteria of best practices badging is defined at [Badging Criteria - BadgeApp](https://bestpractices.coreinfrastructure.org/en/criteria/0). We recommend that all projects obtain a best practices badge and that projects determine the desired badging level early in the development cycle and include it in the project milestones, to ensure efforts towards security as accounted for, managed and tracked. As adoption increases and the project becomes more critical, also consider increasing the badging level. As an example of defining this activity, you could consider passing a bronze/silver badging level prior to the "x" release of the project and aim to attain gold badging level within a defined timeframe.
+
+## 6. OpenSSF Security Scorecards
+
+The [OpenSSF Scorecards](https://securityscorecards.dev/) project helps quickly assess your project for risky practices. You can run the tool via the CLI manually or integrate it into your build [via a GitHub Action](https://securityscorecards.dev/#using-the-github-action). There are a variety of checks that are executed by default and the tool is even extensible to allow you to add your own checks. The CNCF highly recommends that projects enable this tool by default and it is integrated into CNCF onboarding tools such as [CLOMonitor](https://clomonitor.io/) or external tools such as deps.dev and more.
+
+## References
+
+1. [CNCF Cloud Native Security Whitepaper][1]
+2. [CNCF Software Supply Chain Best Practices Whitepaper][2]
+3. [CNCF Cloud Native Security Map][3]
+4. [OpenSSF Badge program][4]
+5. [CNCF TAG Security Publications][5]
+6. [OpenSSF Scorecards][6]
+7. [CLOMonitor][7]
+
+## Contributors
+
+- Ragashree M C
+- Chris Aniszczyk
+
+## Reviewers
+
+- Andrew Martin (CNCF TAG Security Co-Chair)
+- Brandon Lum (CNCF TAG Security Co-Chair)
+- Emily Fox (CNCF TOC Security Liaison)
+- Justin Cormack (CNCF TOC Security Liaison)
+- Faisal Razzak
+- Justin Cappos
+- Marco De Benedictis
+- Sergey Pronin
+- Shlomo Zalman Heigh
+
+## Acknowledgements
+
+This paper is influenced by the publications of CNCF Technical Advisory Group for Security, particularly the Cloud Native Security Whitepaper[[1]] and Software Supply Chain Security Best Practices Whitepaper,[[2]] and CNCF Cloud Native Security Map[[3]], programs and initiatives by OpenSSF[[4]] [[6]]. Our sincere gratitude for the contributors of these programs and publications, and to Emily Fox for suggesting the creation of this paper, to the contributors and reviewers of this paper.
+
+[1]: /security-whitepaper/v2/cloud-native-security-whitepaper.md
+[2]: /supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf
+[3]: https://cnsmap.github.io/
+[4]: https://bestpractices.coreinfrastructure.org/en
+[5]: /publications/README.md
+[6]: https://securityscorecards.dev/
+[7]: https://clomonitor.io/
diff --git a/project-resources/templates/ISSUE_TEMPLATE.md b/community/resources/project-resources/templates/ISSUE_TEMPLATE.md
similarity index 100%
rename from project-resources/templates/ISSUE_TEMPLATE.md
rename to community/resources/project-resources/templates/ISSUE_TEMPLATE.md
diff --git a/project-resources/templates/SECURITY.md b/community/resources/project-resources/templates/SECURITY.md
similarity index 100%
rename from project-resources/templates/SECURITY.md
rename to community/resources/project-resources/templates/SECURITY.md
diff --git a/project-resources/templates/SECURITY_CONTACTS.md b/community/resources/project-resources/templates/SECURITY_CONTACTS.md
similarity index 100%
rename from project-resources/templates/SECURITY_CONTACTS.md
rename to community/resources/project-resources/templates/SECURITY_CONTACTS.md
diff --git a/project-resources/templates/embargo-policy.md b/community/resources/project-resources/templates/embargo-policy.md
similarity index 100%
rename from project-resources/templates/embargo-policy.md
rename to community/resources/project-resources/templates/embargo-policy.md
diff --git a/project-resources/templates/embargo.md b/community/resources/project-resources/templates/embargo.md
similarity index 100%
rename from project-resources/templates/embargo.md
rename to community/resources/project-resources/templates/embargo.md
diff --git a/project-resources/templates/incident-response.md b/community/resources/project-resources/templates/incident-response.md
similarity index 100%
rename from project-resources/templates/incident-response.md
rename to community/resources/project-resources/templates/incident-response.md
diff --git a/provenance-implementation/README.md b/community/resources/provenance-implementation/README.md
similarity index 100%
rename from provenance-implementation/README.md
rename to community/resources/provenance-implementation/README.md
diff --git a/provenance-implementation/argo/argo-cd.md b/community/resources/provenance-implementation/argo/argo-cd.md
similarity index 100%
rename from provenance-implementation/argo/argo-cd.md
rename to community/resources/provenance-implementation/argo/argo-cd.md
diff --git a/security-fuzzing-handbook/README.md b/community/resources/security-fuzzing-handbook/README.md
similarity index 100%
rename from security-fuzzing-handbook/README.md
rename to community/resources/security-fuzzing-handbook/README.md
diff --git a/security-fuzzing-handbook/build.sh b/community/resources/security-fuzzing-handbook/build.sh
similarity index 100%
rename from security-fuzzing-handbook/build.sh
rename to community/resources/security-fuzzing-handbook/build.sh
diff --git a/security-fuzzing-handbook/fuzzing-handbook.md b/community/resources/security-fuzzing-handbook/fuzzing-handbook.md
similarity index 99%
rename from security-fuzzing-handbook/fuzzing-handbook.md
rename to community/resources/security-fuzzing-handbook/fuzzing-handbook.md
index 2825c710c..5f7e0f8b2 100644
--- a/security-fuzzing-handbook/fuzzing-handbook.md
+++ b/community/resources/security-fuzzing-handbook/fuzzing-handbook.md
@@ -1780,7 +1780,7 @@ In the `project.yaml` we enabled issue reporting via GitHub, specifically `file_
 
 ![OSS-Fuzz auto-bot reporting a bug](imgs/OSS-Fuzz-GitHub-bot-reporting-an-issue.png)
 
-In addition to the GitHub issue we also received an email notification at the same time, with the exact same content as in the GitHub issue. This email was sent out to all emails listed in the project.yaml. The content of the text is scarce and to extract more insights we need to follow the links in the description to bug reports. There are two links to further details about the issue, one for https://bugs.chromium.org/… and one for https://oss-fuzz.com/… The bug report on https://oss-fuzz.com/… has the most details and will always remain only visible to the emails listed in project.yaml and the details listed on https://bugs.chromium.org/… has slightly more information about the bug report than the GitHub issue and this report will remain private until the bug disclosure deadlines has passed, which is 90 days, or until the issue is fixed.
+In addition to the GitHub issue we also received an email notification at the same time, with the exact same content as in the GitHub issue. This email was sent out to all emails listed in the project.yaml. The content of the text is scarce and to extract more insights we need to follow the links in the description to bug reports. There are two links to further details about the issue, one for https://bugs.chromium.org/ and one for https://oss-fuzz.com/. The bug report on https://oss-fuzz.com/ has the most details and will always remain only visible to the emails listed in project.yaml and the details listed on https://bugs.chromium.org/ has slightly more information about the bug report than the GitHub issue and this report will remain private until the bug disclosure deadlines has passed, which is 90 days, or until the issue is fixed.
 
 
 ### Viewing detailed bug reports
diff --git a/security-fuzzing-handbook/handbook-fuzzing.pdf b/community/resources/security-fuzzing-handbook/handbook-fuzzing.pdf
similarity index 100%
rename from security-fuzzing-handbook/handbook-fuzzing.pdf
rename to community/resources/security-fuzzing-handbook/handbook-fuzzing.pdf
diff --git a/security-fuzzing-handbook/imgs/Code-coverage-of-example-project.png b/community/resources/security-fuzzing-handbook/imgs/Code-coverage-of-example-project.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Code-coverage-of-example-project.png
rename to community/resources/security-fuzzing-handbook/imgs/Code-coverage-of-example-project.png
diff --git a/security-fuzzing-handbook/imgs/Coverage-guided-fuzzing-overview.png b/community/resources/security-fuzzing-handbook/imgs/Coverage-guided-fuzzing-overview.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Coverage-guided-fuzzing-overview.png
rename to community/resources/security-fuzzing-handbook/imgs/Coverage-guided-fuzzing-overview.png
diff --git a/security-fuzzing-handbook/imgs/Function-level-fuzzing-introspection.png b/community/resources/security-fuzzing-handbook/imgs/Function-level-fuzzing-introspection.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Function-level-fuzzing-introspection.png
rename to community/resources/security-fuzzing-handbook/imgs/Function-level-fuzzing-introspection.png
diff --git a/security-fuzzing-handbook/imgs/Fuzzing-code-coverage-report.png b/community/resources/security-fuzzing-handbook/imgs/Fuzzing-code-coverage-report.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Fuzzing-code-coverage-report.png
rename to community/resources/security-fuzzing-handbook/imgs/Fuzzing-code-coverage-report.png
diff --git a/security-fuzzing-handbook/imgs/Fuzzing-key-components.png b/community/resources/security-fuzzing-handbook/imgs/Fuzzing-key-components.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Fuzzing-key-components.png
rename to community/resources/security-fuzzing-handbook/imgs/Fuzzing-key-components.png
diff --git a/security-fuzzing-handbook/imgs/Historical-progession-of-example-project.png b/community/resources/security-fuzzing-handbook/imgs/Historical-progession-of-example-project.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Historical-progession-of-example-project.png
rename to community/resources/security-fuzzing-handbook/imgs/Historical-progession-of-example-project.png
diff --git a/security-fuzzing-handbook/imgs/LibFuzzer-engine-overview.png b/community/resources/security-fuzzing-handbook/imgs/LibFuzzer-engine-overview.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/LibFuzzer-engine-overview.png
rename to community/resources/security-fuzzing-handbook/imgs/LibFuzzer-engine-overview.png
diff --git a/security-fuzzing-handbook/imgs/Minimized-testcase-provided-per-issue.png b/community/resources/security-fuzzing-handbook/imgs/Minimized-testcase-provided-per-issue.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Minimized-testcase-provided-per-issue.png
rename to community/resources/security-fuzzing-handbook/imgs/Minimized-testcase-provided-per-issue.png
diff --git a/security-fuzzing-handbook/imgs/Monorail-issues-are-closed-automatically.png b/community/resources/security-fuzzing-handbook/imgs/Monorail-issues-are-closed-automatically.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Monorail-issues-are-closed-automatically.png
rename to community/resources/security-fuzzing-handbook/imgs/Monorail-issues-are-closed-automatically.png
diff --git a/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-automatically-closes-issus.png b/community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-automatically-closes-issus.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-automatically-closes-issus.png
rename to community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-automatically-closes-issus.png
diff --git a/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-reporting-an-issue.png b/community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-reporting-an-issue.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-reporting-an-issue.png
rename to community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-GitHub-bot-reporting-an-issue.png
diff --git a/security-fuzzing-handbook/imgs/OSS-Fuzz-detailed-stack-trace.png b/community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-detailed-stack-trace.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/OSS-Fuzz-detailed-stack-trace.png
rename to community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-detailed-stack-trace.png
diff --git a/security-fuzzing-handbook/imgs/OSS-Fuzz-issue-overview.png b/community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-issue-overview.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/OSS-Fuzz-issue-overview.png
rename to community/resources/security-fuzzing-handbook/imgs/OSS-Fuzz-issue-overview.png
diff --git a/security-fuzzing-handbook/imgs/Open-source-fuzz-introspection-overview.png b/community/resources/security-fuzzing-handbook/imgs/Open-source-fuzz-introspection-overview.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Open-source-fuzz-introspection-overview.png
rename to community/resources/security-fuzzing-handbook/imgs/Open-source-fuzz-introspection-overview.png
diff --git a/security-fuzzing-handbook/imgs/Source-level-code-coverage.png b/community/resources/security-fuzzing-handbook/imgs/Source-level-code-coverage.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/Source-level-code-coverage.png
rename to community/resources/security-fuzzing-handbook/imgs/Source-level-code-coverage.png
diff --git a/security-fuzzing-handbook/imgs/cncf-logo-footer.png b/community/resources/security-fuzzing-handbook/imgs/cncf-logo-footer.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/cncf-logo-footer.png
rename to community/resources/security-fuzzing-handbook/imgs/cncf-logo-footer.png
diff --git a/security-fuzzing-handbook/imgs/cncf-stacked-color.png b/community/resources/security-fuzzing-handbook/imgs/cncf-stacked-color.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/cncf-stacked-color.png
rename to community/resources/security-fuzzing-handbook/imgs/cncf-stacked-color.png
diff --git a/security-fuzzing-handbook/imgs/envoy-introspector-profile.png b/community/resources/security-fuzzing-handbook/imgs/envoy-introspector-profile.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/envoy-introspector-profile.png
rename to community/resources/security-fuzzing-handbook/imgs/envoy-introspector-profile.png
diff --git a/security-fuzzing-handbook/imgs/vitess-fuzzing-landscape.png b/community/resources/security-fuzzing-handbook/imgs/vitess-fuzzing-landscape.png
similarity index 100%
rename from security-fuzzing-handbook/imgs/vitess-fuzzing-landscape.png
rename to community/resources/security-fuzzing-handbook/imgs/vitess-fuzzing-landscape.png
diff --git a/security-lexicon/README.md b/community/resources/security-lexicon/README.md
similarity index 100%
rename from security-lexicon/README.md
rename to community/resources/security-lexicon/README.md
diff --git a/security-lexicon/cloud-native-security-lexicon.md b/community/resources/security-lexicon/cloud-native-security-lexicon.md
similarity index 100%
rename from security-lexicon/cloud-native-security-lexicon.md
rename to community/resources/security-lexicon/cloud-native-security-lexicon.md
diff --git a/security-whitepaper/README.md b/community/resources/security-whitepaper/README.md
similarity index 100%
rename from security-whitepaper/README.md
rename to community/resources/security-whitepaper/README.md
diff --git a/security-whitepaper/cnsmap/README.md b/community/resources/security-whitepaper/cnsmap/README.md
similarity index 100%
rename from security-whitepaper/cnsmap/README.md
rename to community/resources/security-whitepaper/cnsmap/README.md
diff --git a/security-whitepaper/secure-defaults-cloud-native-8.md b/community/resources/security-whitepaper/secure-defaults-cloud-native-8.md
similarity index 99%
rename from security-whitepaper/secure-defaults-cloud-native-8.md
rename to community/resources/security-whitepaper/secure-defaults-cloud-native-8.md
index f5d11c3f1..be03d65c7 100644
--- a/security-whitepaper/secure-defaults-cloud-native-8.md
+++ b/community/resources/security-whitepaper/secure-defaults-cloud-native-8.md
@@ -3,7 +3,7 @@
 <!-- cspell:disable -->
 **Author**: Pushkar Joglekar
 
-**Contributors** (alphabetical order): Andres Vega, Emily Fox, Faraz Angabini,
+**Contributors** (alphabetical order): Emily Fox, Faraz Angabini,
 Robert Clark, Robert Van Voorhees
 <!-- cspell:enable -->
 
diff --git a/security-whitepaper/v1/CNCF_cloud-native-security-whitepaper-Nov2020.pdf b/community/resources/security-whitepaper/v1/CNCF_cloud-native-security-whitepaper-Nov2020.pdf
similarity index 100%
rename from security-whitepaper/v1/CNCF_cloud-native-security-whitepaper-Nov2020.pdf
rename to community/resources/security-whitepaper/v1/CNCF_cloud-native-security-whitepaper-Nov2020.pdf
diff --git a/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md b/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md
similarity index 100%
rename from security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md
rename to community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-brazilian-portugese.md
diff --git a/security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md b/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md
similarity index 100%
rename from security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md
rename to community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-simplified-chinese.md
diff --git a/security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md b/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md
similarity index 99%
rename from security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md
rename to community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md
index a5f569805..8821293aa 100644
--- a/security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md
+++ b/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper-spanish.md
@@ -317,7 +317,7 @@ Con respecto a los objetivos de las garantías de seguridad, se deben evaluar la
 
 #### Etapa de Pruebas 
 
-Las aplicaciones nativas para la nube deben estar sujetas al mismo conjunto y estándar de pruebas de calidad que las aplicaciones tradicionales. Estos incluyen conceptos de código limpio, adhesión a la [Pirámide de Prueba]((https://martinfowler.com/articles/practical-test-pyramid.html)), escaneo de seguridad de aplicación y linting a través de pruebas de la seguridad de aplicaciones estáticas (SAST), análisis y escaneo de dependencias, pruebas de seguridad de aplicaciones dinámicas (DAST) (por ejemplo, mocking), instrumentación de aplicación e infraestructura completa con pruebas disponibles para los desarrolladores en flujos de trabajo locales. Los resultados de las pruebas automatizadas deben regresar a los requisitos para una comprobación dual (desarrollador y herramienta) para garantizar la seguridad en tiempo real a los equipos de seguridad y el cumplimiento normativo.
+Las aplicaciones nativas para la nube deben estar sujetas al mismo conjunto y estándar de pruebas de calidad que las aplicaciones tradicionales. Estos incluyen conceptos de código limpio, adhesión a la [Pirámide de Prueba](https://martinfowler.com/articles/practical-test-pyramid.html), escaneo de seguridad de aplicación y linting a través de pruebas de la seguridad de aplicaciones estáticas (SAST), análisis y escaneo de dependencias, pruebas de seguridad de aplicaciones dinámicas (DAST) (por ejemplo, mocking), instrumentación de aplicación e infraestructura completa con pruebas disponibles para los desarrolladores en flujos de trabajo locales. Los resultados de las pruebas automatizadas deben regresar a los requisitos para una comprobación dual (desarrollador y herramienta) para garantizar la seguridad en tiempo real a los equipos de seguridad y el cumplimiento normativo.
 Una vez que se ha identificado un error de seguridad (por ejemplo, un firewall incorrecto o una regla de enrutamiento), si el análisis de la causa raíz determina que tiene una posibilidad razonable de recurrencia, los desarrolladores deben escribir una prueba automatizada para evitar la regresión del defecto. En la falla de la prueba, los equipos recibirán comentarios para corregir el error y con la próxima fusión, la prueba pasará (suponiendo que fue corregido). Hacer esto, defiende contra la regresión debido a los cambios futuros en ese código.
 
 Las pruebas unitarias de la infraestructura es un control preventivo y se dirige a las entidades y entradas definidas en la configuración de infraestructura como código (IaC). Las pruebas de seguridad de la infraestructura construida son un control de detección y combinan garantía, regresiones históricas y detección de configuración inesperada (reglas de firewall abiertas al mundo, políticas de demasiado acceso privilegiado y manejo de acceso (IAM), endpoints no autenticados, etc.).
@@ -540,7 +540,7 @@ Especificar el UID o GID del volumen sigue permitiendo el acceso del contenedor
 ##### Registros de Artefactos
 
 Los registros deben incluir tecnologías para firmar y verificar los artefactos de OCI. También es importante asegurarse de que las herramientas de almacenamiento en caché y distribución también proporcionen la capacidad de firmar, cifrar y proporcionar sumas de comprobación para garantizar que la capa de caché pueda detectar manipulaciones o intentos de envenenar el conjunto de datos.
-El documento técnico [v2]((https://bit.ly/cncf-storage-whitepaperV2)) sobre almacenamiento de la CNCF proporciona información adicional sobre los conceptos, la terminología, los patrones de uso y las clases de tecnología del almacenamiento nativo en la nube.
+El documento técnico [v2](https://bit.ly/cncf-storage-whitepaperV2)) sobre almacenamiento de la CNCF proporciona información adicional sobre los conceptos, la terminología, los patrones de uso y las clases de tecnología del almacenamiento nativo en la nube.
 
 ### Acceso
 
diff --git a/security-whitepaper/v1/cloud-native-security-whitepaper.md b/community/resources/security-whitepaper/v1/cloud-native-security-whitepaper.md
similarity index 100%
rename from security-whitepaper/v1/cloud-native-security-whitepaper.md
rename to community/resources/security-whitepaper/v1/cloud-native-security-whitepaper.md
diff --git a/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure1.png b/community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure1.png
similarity index 100%
rename from security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure1.png
rename to community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure1.png
diff --git a/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure2.png b/community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure2.png
similarity index 100%
rename from security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure2.png
rename to community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure2.png
diff --git a/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure3.png b/community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure3.png
similarity index 100%
rename from security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure3.png
rename to community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure3.png
diff --git a/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure4.png b/community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure4.png
similarity index 100%
rename from security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure4.png
rename to community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure4.png
diff --git a/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure5.png b/community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure5.png
similarity index 100%
rename from security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure5.png
rename to community/resources/security-whitepaper/v1/cnswp-images/RackMultipart20201111_figure5.png
diff --git a/security-whitepaper/v1/secure-software-factory.md b/community/resources/security-whitepaper/v1/secure-software-factory.md
similarity index 100%
rename from security-whitepaper/v1/secure-software-factory.md
rename to community/resources/security-whitepaper/v1/secure-software-factory.md
diff --git a/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf b/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf
similarity index 100%
rename from security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf
rename to community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf
diff --git a/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf b/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf
similarity index 100%
rename from security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf
rename to community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-cn-Sept2023-v2.pdf
diff --git a/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-it-May2023-v2.pdf b/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-it-May2023-v2.pdf
similarity index 100%
rename from security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-it-May2023-v2.pdf
rename to community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-it-May2023-v2.pdf
diff --git a/security-whitepaper/v2/cloud-native-security-whitepaper-it.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md
similarity index 100%
rename from security-whitepaper/v2/cloud-native-security-whitepaper-it.md
rename to community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-it.md
diff --git a/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md
similarity index 100%
rename from security-whitepaper/v2/cloud-native-security-whitepaper-ja.md
rename to community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-ja.md
diff --git a/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md
similarity index 100%
rename from security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md
rename to community/resources/security-whitepaper/v2/cloud-native-security-whitepaper-simplified-chinese.md
diff --git a/security-whitepaper/v2/cloud-native-security-whitepaper.md b/community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md
similarity index 100%
rename from security-whitepaper/v2/cloud-native-security-whitepaper.md
rename to community/resources/security-whitepaper/v2/cloud-native-security-whitepaper.md
diff --git a/security-whitepaper/v2/cnswp-images/cnswp-v2-figure1.png b/community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-figure1.png
similarity index 100%
rename from security-whitepaper/v2/cnswp-images/cnswp-v2-figure1.png
rename to community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-figure1.png
diff --git a/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-deploy.png b/community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-deploy.png
similarity index 100%
rename from security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-deploy.png
rename to community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-deploy.png
diff --git a/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-develop.png b/community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-develop.png
similarity index 100%
rename from security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-develop.png
rename to community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-develop.png
diff --git a/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-distribute.png b/community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-distribute.png
similarity index 100%
rename from security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-distribute.png
rename to community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-distribute.png
diff --git a/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-runtime.png b/community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-runtime.png
similarity index 100%
rename from security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-runtime.png
rename to community/resources/security-whitepaper/v2/cnswp-images/cnswp-v2-security-structural-model-runtime.png
diff --git a/usecase-personas/README.md b/community/resources/usecase-personas/README.md
similarity index 100%
rename from usecase-personas/README.md
rename to community/resources/usecase-personas/README.md
diff --git a/usecase-personas/references/admin-bill-of-rights.md b/community/resources/usecase-personas/references/admin-bill-of-rights.md
similarity index 100%
rename from usecase-personas/references/admin-bill-of-rights.md
rename to community/resources/usecase-personas/references/admin-bill-of-rights.md
diff --git a/community/supply-chain-security/README.md b/community/supply-chain-security/README.md
deleted file mode 100644
index 1cd84d8e1..000000000
--- a/community/supply-chain-security/README.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Software Supply Chain Security
-
-Software Supply Chain attacks have come to the wider community's attention following a recent high-profile attack, but have been an ongoing threat for a long time. With the ever-growing importance of free and open source software, software supply chain security is crucial, particularly in cloud native environments where everything is software-defined.
-
-## Meeting Information
-
-- **Weekly Meetings:** 8:00 AM Pacific Time (US and Canada)
-- **Meeting Link:** See CNCF calendar for invite
-- **Meeting Notes:** [Google Docs](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit#heading=h.xkkh09c7ni6)
-
-## Contact
-
-- **Lead:** Marina Moore, Michael Lieberman, John Kjell
-- **Slack Channel:** [Link](https://cloud-native.slack.com/archives/C01KL0B4LKC)
diff --git a/policy/PolicyFormalVerificationDiagram.png b/community/working-groups/archive/policy/PolicyFormalVerificationDiagram.png
similarity index 100%
rename from policy/PolicyFormalVerificationDiagram.png
rename to community/working-groups/archive/policy/PolicyFormalVerificationDiagram.png
diff --git a/policy/overview-formal-verification.png b/community/working-groups/archive/policy/overview-formal-verification.png
similarity index 100%
rename from policy/overview-formal-verification.png
rename to community/working-groups/archive/policy/overview-formal-verification.png
diff --git a/policy/overview-policy-build-time-dependency-vulns.md b/community/working-groups/archive/policy/overview-policy-build-time-dependency-vulns.md
similarity index 100%
rename from policy/overview-policy-build-time-dependency-vulns.md
rename to community/working-groups/archive/policy/overview-policy-build-time-dependency-vulns.md
diff --git a/policy/overview-policy-formal-verification.md b/community/working-groups/archive/policy/overview-policy-formal-verification.md
similarity index 100%
rename from policy/overview-policy-formal-verification.md
rename to community/working-groups/archive/policy/overview-policy-formal-verification.md
diff --git a/community/automated-governance/README.md b/community/working-groups/automated-governance/README.md
similarity index 100%
rename from community/automated-governance/README.md
rename to community/working-groups/automated-governance/README.md
diff --git a/community/compliance/README.md b/community/working-groups/compliance/README.md
similarity index 100%
rename from community/compliance/README.md
rename to community/working-groups/compliance/README.md
diff --git a/community/controls/README.md b/community/working-groups/controls/README.md
similarity index 100%
rename from community/controls/README.md
rename to community/working-groups/controls/README.md
diff --git a/cloud-native-controls/phase-one-announcement.md b/community/working-groups/controls/phase-one-announcement.md
similarity index 100%
rename from cloud-native-controls/phase-one-announcement.md
rename to community/working-groups/controls/phase-one-announcement.md
diff --git a/community/research/README.md b/community/working-groups/research/README.md
similarity index 100%
rename from community/research/README.md
rename to community/working-groups/research/README.md
diff --git a/community/working-groups/supply-chain-security/README.md b/community/working-groups/supply-chain-security/README.md
new file mode 100644
index 000000000..bcaefee5c
--- /dev/null
+++ b/community/working-groups/supply-chain-security/README.md
@@ -0,0 +1,41 @@
+# Software Supply Chain Security
+
+Software Supply Chain attacks have come to the wider community's attention following a recent high-profile attack, but have been an ongoing threat for a long time. With the ever-growing importance of free and open source software, software supply chain security is crucial, particularly in cloud native environments where everything is software-defined.
+
+## What are supply chain vulnerabilities and their implications?
+
+The [Catalog of Supply Chain Compromises](../../catalog/compromises/) provides real-world
+examples that help raise awareness and provide detailed information that
+let's us understand attack vectors and consider how to mitigate potential
+risk.
+
+## On mitigating vulnerabilities
+
+There is on-going work to establish best practices in this area. The list of
+[types of supply chain compromises](../../catalog/compromises/compromise-definitions.md)
+in the [catalog of supply chain compromises](../../catalog/compromises/) suggests some
+mitigation techniques for the more well understood categories.
+
+## Supply chain security paper
+
+STAG (Security Technical Advisory Group) has put work into a comprehensive
+software supply chain paper highlighting best practices for high and medium risk
+environments. Please check out
+[the paper](./supply-chain-security-paper/sscsp.md)
+and corollary
+[secure supply chain assessment document](./supply-chain-security-paper/secure-supply-chain-assessment.md)
+to learn more.
+
+For information about contributing to the document or providing feedback, please
+refer to the [README](./supply-chain-security-paper/README.md).
+
+## Meeting Information
+
+- **Weekly Meetings:** 8:00 AM Pacific Time (US and Canada)
+- **Meeting Link:** See CNCF calendar for invite
+- **Meeting Notes:** [Google Docs](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit#heading=h.xkkh09c7ni6)
+
+## Contact
+
+- **Lead:** Marina Moore, Michael Lieberman, John Kjell
+- **Slack Channel:** [Link](https://cloud-native.slack.com/archives/C01KL0B4LKC)
diff --git a/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf b/community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf
similarity index 100%
rename from supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf
rename to community/working-groups/supply-chain-security/secure-software-factory/Secure_Software_Factory_Whitepaper.pdf
diff --git a/supply-chain-security/secure-software-factory/images/image1.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image1.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image1.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image1.png
diff --git a/supply-chain-security/secure-software-factory/images/image2.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image2.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image2.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image2.png
diff --git a/supply-chain-security/secure-software-factory/images/image3.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image3.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image3.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image3.png
diff --git a/supply-chain-security/secure-software-factory/images/image4.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image4.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image4.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image4.png
diff --git a/supply-chain-security/secure-software-factory/images/image5.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image5.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image5.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image5.png
diff --git a/supply-chain-security/secure-software-factory/images/image6.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image6.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image6.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image6.png
diff --git a/supply-chain-security/secure-software-factory/images/image7.png b/community/working-groups/supply-chain-security/secure-software-factory/images/image7.png
similarity index 100%
rename from supply-chain-security/secure-software-factory/images/image7.png
rename to community/working-groups/supply-chain-security/secure-software-factory/images/image7.png
diff --git a/supply-chain-security/secure-software-factory/secure-software-factory.md b/community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md
similarity index 100%
rename from supply-chain-security/secure-software-factory/secure-software-factory.md
rename to community/working-groups/supply-chain-security/secure-software-factory/secure-software-factory.md
diff --git a/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf b/community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf
diff --git a/supply-chain-security/supply-chain-security-paper/README.md b/community/working-groups/supply-chain-security/supply-chain-security-paper/README.md
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/README.md
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/README.md
diff --git a/supply-chain-security/supply-chain-security-paper/fig1.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig1.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig1.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig1.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig2.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig2.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig2.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig2.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig3.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig3.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig3.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig3.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig4.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig4.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig4.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig4.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig5.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig5.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig5.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig5.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig6.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig6.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig6.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig6.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig7.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig7.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig7.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig7.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig8.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig8.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig8.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig8.png
diff --git a/supply-chain-security/supply-chain-security-paper/fig9.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/fig9.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/fig9.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/fig9.png
diff --git a/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md b/community/working-groups/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/secure-supply-chain-assessment.md
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig1.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig1.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig1.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig1.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig2.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig2.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig2.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig2.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig3.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig3.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig3.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig3.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig4.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig4.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig4.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig4.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig5.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig5.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig5.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig5.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig6.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig6.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig6.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig6.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig7.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig7.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig7.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig7.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig8.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig8.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig8.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig8.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp-images/fig9.png b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig9.png
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp-images/fig9.png
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp-images/fig9.png
diff --git a/supply-chain-security/supply-chain-security-paper/sscsp.md b/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp.md
similarity index 100%
rename from supply-chain-security/supply-chain-security-paper/sscsp.md
rename to community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp.md
diff --git a/compliance/README.md b/compliance/README.md
deleted file mode 100644
index 36db9a775..000000000
--- a/compliance/README.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# CNCF Compliance Working Group
-
-## Charter
-
-Cloud Native systems represent a paradigm shift in both technical and human operations workflows.  The community (and industry) has invested significant time researching and solving
-approaches to Cloud native security concerns and topics: software vulnerabilities, risk management, software component dependencies and infrastructure as code (GitOps), supply chain
-provenance, malicious attackers, threat models, and technical security assessments.  At the same time, many commercial, non-profit foundations, community and government organizations
-performing services or providing data storage must abide by national, regional, or local laws and regulations regarding user privacy and data, with assurance of protection of their compute
-and data processing integrity and resilience. These cross cutting concerns span not only specific technical configuration of software and systems, but also require complex orchestration of
-human administrative, operational, and design activities, especially when involving  audit activities expecting concrete, reviewable independent audit artifacts.
-
-The motivation of the Compliance WG is cross-disciplinary and focused on bridging purely technical issues to broader legal and regulatory workflows: not only to strive for the prevention
-of system breaches, but also considering supply chain, operators, data and AI failures while simultaneously considering auditability, non-repudiation, legally required forensic evidence,
-etc. - across all the various activities required of cloud native operators of all sizes. The Compliance WG plans to curate vendor neutral tools for evidence collection, chain-of-custody
-in audits, as well as automated workflows for continuous compliance authoring and assessment.
-
-The key areas of the Compliance WG include:
-
-- Building a knowledge base (in GitHub and possibly other tools) and case studies on the How, What, Why and When of operating a cloud native environment within the requirements of legal
-and regulatory entities that govern clouds, specific industries, and more generally data and public/consumer usage. These requirements are often _not just_  technical security concerns.
-Compliance activities and requirements span human activities and performance, system availability and reliability, the combined human and technical aspects of continuity of operations,
-defining and monitoring data location as well as sovereignty and provenance of the regulated environment components and data
-
-- Generating specific examples of compliance as code, normalized templates, and tools for automating these both technical and non-technical requirements, control assessment, data analysis,
-audit and compliance remediation workflows that specifically benefit CNCF projects and their community of users.
-
-- Reviewing industry and governmental standards - eg NIST, PCI, HIPAA, etc - from a cloud native perspective and serving as Subject Matter Experts in the CNCF community for how projects
-should implement and support these compliance-specific requirements as first class citizen to enable broad adoption of the best practices by commercial, non-profit, governmental, and
-humanitarian organizations.
-
-## Responsibilities
-
-<!-- cSpell:disable -->
-
-- Users/personas/needs/customer demands for industry and regulatory compliance (both human and technical)
-- Identifications of areas of focus e.g. human workflows, automated workflows, analytical tools, audit and assessment tools, technical security controls that cut across components and systems and clouds, etc
-- Framework for evaluation, audit and reporting - how do products and tools demonstrate compliance?
-- Training and automation - what is missing, what is difficult to understand, what knowledge gaps are there?
-- Work on integrating common tooling across different projects, particularly where that tooling is a CNCF project (but the targets may not be)
-- Cross project focus on the projects and efforts the CNCF is funding, helping projects identify needs and providing subject matter expertise to assist
-- Recommendations of integrating security tooling with compliance tooling and processes - making both the synergies and unique separations of concern explicit and achieving community consensus.
-- Growing CNCF external relationships with interested parties, e.g. NIST and other compliance standards bodies such as FINOS, OSCAL, OpenSSF
-
-## Stakeholders/Key people - Roles and responsibilities
-
-<!-- cSpell:disable -->
-
-### WG co-chairs
-
-- Anca Sailer ([@ancatri](https://github.com/ancatri))
-
-- Robert Ficcaglia ([@rficcaglia](https://github.com/rficcaglia))
-
-### WG tech leads
-
-- Alejandro Leiva ([@AleJo2995](https://github.com/AleJo2995))
-
-- Jennifer Power ([@jpower432](https://github.com/jpower432))
-
-- Lou DeGenaro ([@degenaro](https://github.com/degenaro))
-
-- Manjiree Gadgil ([@mrgadgil](https://github.com/mrgadgil))
-
-- Vikas Agarwal ([@vikas-agarwal76](https://github.com/vikas-agarwal76))
-
-- Yuji Watanabe ([@yuji-watanabe-jp](https://github.com/yuji-watanabe-jp))
-
-- Takumi Yanagawa ([@yana1205](https://github.com/yana1205))
diff --git a/docker-compose.yml b/docker-compose.yml
index 09a11250b..a35f2433a 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -1,5 +1,4 @@
 ---
-version: '2'
 services:
   setup:
     image: node:18
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/blog-guidelines.md b/governance/blog-guidelines.md
new file mode 100644
index 000000000..601501580
--- /dev/null
+++ b/governance/blog-guidelines.md
@@ -0,0 +1,113 @@
+# Blog Guidelines
+
+## Introduction
+
+Welcome to the Security TAG (STAG) Blog! Our blog is a platform for sharing insights, experiences, and knowledge about Cloud Native software and the community. We encourage contributions from community members to help educate, inspire, and engage others. To ensure quality and consistency, we have established the following guidelines for content creation, submission review, and the overall value to the community.
+
+## Proposal
+
+Everyone is welcome to propose a new blog post using the [blog submission template](https://github.com/cncf/tag-security/blob/main/.github/ISSUE_TEMPLATE/blog-submission.md). Blog article proposals are meant to capture the intent of authoring one of many topics covered below.
+
+## Content Creation
+
+### Topics
+
+- **Cloud Native Projects**: Share updates, features, and success stories.
+- **Technical Tutorials**: Provide how-to guides, coding tips, and best practices.
+- **Community Stories**: Highlight contributors, events, and community achievements.
+- **Working Groups**: Proposed initiatives, Updates, and calls to action.
+- **Opinion Pieces**: Discuss trends, challenges, and the future of open source.
+
+### Writing Style
+
+- **Clarity**: Write in clear, concise language. Avoid jargon unless it's well-explained.
+- **Engagement**: Make your post interesting and engaging. Use anecdotes and examples.
+- **Accuracy**: Ensure all information is accurate and up-to-date.
+- **Inclusivity**: Use inclusive language and be respectful to all readers.
+
+### Formatting
+
+- **File Name**: Blog Files should be dash-case `.md` markdown filetype.
+- **Headings**: Use appropriate headings (H1, H2, H3, etc.) to structure your post.
+- **Paragraphs**: Keep paragraphs short and focused.
+- **Lists**: Use bullet points or numbered lists to highlight key points.
+- **Tags**: Include relevant tags in the blog for filtering capabilities.
+- **Code**: Use code blocks for any code snippets.
+- **Images**: Include relevant images and graphics to enhance the content.
+
+### Front Matter
+
+The start of each blog document should contain the `frontmatter` information.
+
+Required `frontmatter` fields:
+
+- **title**: Title-case title for the blog post
+- **author**: Name of blog post author
+
+Note: **date** can be included but will be appended to the `frontmatter` when publication date is decided.
+
+#### Example
+
+```yaml
+---
+title:  "New Informative Blog Post"
+date:   2024-06-26 09:00:00 -0700
+author: R. Raccoon
+---
+```
+
+### Length
+
+- Aim for 500-1200 words. Ensure the content is comprehensive yet concise.
+
+## Submission Review Process
+
+### Submission
+
+1. **Draft**: Write your blog post in a markdown file under `tag-security/website/content/blog`.
+2. **Pull Request**: Submit your draft in a pull request.
+
+### Review
+
+1. **Initial Review**: The collective team will perform an initial review.
+2. **Feedback**: You may receive feedback and requests for revisions.
+3. **Revisions**: Address the feedback and resubmit your revised draft.
+4. **Final Review**: The team conducts a final review to ensure quality.
+
+### Reviewer Criteria
+
+1. **Content**: Submission abides by all `Content Creation` guidelines established above.
+2. **Sponsor**: Submission is sponsored by a STAG Co-Chair, Tech Lead, or Project Lead.
+3. **Existing Content**: Submission does not duplicate existing material.
+
+### Approval
+
+- **Acceptance**: Once approved, your post will be scheduled for publication.
+- **Notification**: You will be notified of the publication date - a repo maintainer may update this field prior to merge.
+- **Merge**: A repository maintainer will perform the merge once accepted.
+
+## Value to the Community
+
+### Education
+
+- **Knowledge Sharing**: Help others learn new skills and techniques.
+- **Resources**: Provide valuable resources and references.
+
+### Inspiration
+
+- **Success Stories**: Inspire others with success stories and case studies.
+- **Innovation**: Encourage innovative thinking and solutions.
+
+### Engagement
+
+- **Discussion**: Foster discussions and interactions within the community.
+- **Support**: Offer support and encouragement to fellow community members.
+
+### Growth
+
+- **Visibility**: Gain visibility for your contributions and projects.
+- **Network**: Call for contribution to get others involved in initiatives.
+
+## Conclusion
+
+Thank you for your interest in contributing to the STAG Blog. By following these guidelines, you help maintain the quality and integrity of our content, benefiting the entire community. We look forward to your valuable contributions!
diff --git a/governance/charter.md b/governance/charter.md
deleted file mode 100644
index 0fd637eff..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](cncf-projects.md), 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).
diff --git a/governance/cncf-projects.md b/governance/cncf-projects.md
deleted file mode 100644
index 5acf48c74..000000000
--- a/governance/cncf-projects.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## CNCF Projects
-
-The CNCF TOC identifies specific project that provide capabilities related
-to security, including policy, identity, authentication, authorization,
-auditing, compliance, cost management, etc.
-
-These are known as "Security Providers" and the TAG will prioritize review of
-each project's annual [security assessment](/assessments).
-
-Current list of projects:
-
-* Falco
-* Harbor
-* in-toto
-* Keycloak
-* Open Policy Agent
-* Notary
-* TUF
-* SPIFFE
-* SPIRE
diff --git a/governance/communications/README.md b/governance/communications/README.md
deleted file mode 100644
index 82f332ae7..000000000
--- a/governance/communications/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Communications
-
-This folder contains templates and processes on communicating with the Security
-TAG community.
-| Templates | Use |
-| -- | -- |
-| [Call to action](call-to-action.md) | For papers, projects, and other efforts sent to the [mailing list](https://lists.cncf.io/g/cncf-tag-security)
diff --git a/governance/communications/call-to-action.md b/governance/communications/call-to-action.md
deleted file mode 100644
index d4d6a4cf2..000000000
--- a/governance/communications/call-to-action.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Call to Action Template
-
-## Security Enthusiasts!
-CNCF Security Tag is looking to embark on another tech security adventure!  [2 sentences explanation of what the thing is].
-[background about why this exists, about 2-3 sentences].  We'd like some help.
- 
-## We want you!
-This is where you (yes you!) come in.  We're looking for community members and colleagues [review/contribute] to this [what the thing is called], tracked under [issue number and link to issue], so that we can provide the cloud native community with [what the intent is]!
-[what this means for the community]. We hope you can join us on this significant contribution opportunity. [If needed by a specific date, say so here].
-
-## Ready to dive in?  
-Comment on the issue [relink the issue] (#XXX) and join the [link to the slack channel] Slack channel!
-
-## References
-[Relink everything again here with what it is and the URLs blown out (not embedded)]
-
-Examples:
-* https://lists.cncf.io/g/cncf-tag-security/message/58
-* https://lists.cncf.io/g/cncf-tag-security/message/54
-* https://lists.cncf.io/g/cncf-tag-security/message/53
diff --git a/governance/roles.md b/governance/roles.md
index 238fa0f9b..ab3b1acec 100644
--- a/governance/roles.md
+++ b/governance/roles.md
@@ -20,12 +20,11 @@ The various roles are listed as follows:
 * [Facilitation roles](#facilitation-roles)
   * [Security assessment facilitator](#security-assessment-facilitator)
   * [Meeting facilitator](#meeting-facilitator)
-  * [Meeting scribe(s)](#meeting-scribe(s))
+  * [Meeting scribe](#meeting-scribe)
   * [Triage team](#triage-team)
   * [Project teams](#project-teams)
 
-All members are identified in the TAG [README](/README.md), with annotations
-where they hold an additional role.
+All chairs and leads are identified in the TAG [README](/README.md).
 
 Members fulfilling any Roles in Security TAG are responsible for understanding
 and abiding the by the [governance](./) and policies defined in this group. This
@@ -41,8 +40,6 @@ consider their actions to support the group.
 ## Role of members
 
 * The primary role of a member is to contribute expertise to the group.
-* To add yourself as a member, submit a Pull Request (PR) adding yourself to the
-  list of members.
 
 ### Maintaining active members
 
@@ -62,7 +59,6 @@ consider their actions to support the group.
 
 ### Managing membership
 
-
 * Membership disagreements may be escalated to the Chairs.  Disagreements
   among the Chairs may be escalated to a Security TAG TOC Liaison.
 * Members *MAY* decide to step down at anytime and optionally propose a
@@ -80,10 +76,10 @@ navigate a complex security landscape.
 * The Chairs are responsible for ensuring that group meetings are planned
   and have facilitators assigned, while also engaging group members in leadership
   roles.
- * Chairs are responsible for approving Pull Requests, specifically for
-   top-level content of the repository
- * Chairs may additionally perform any actions of technical leads as needed,
-   especially serving as the Security TAG leadership representative to a project.
+* Chairs are responsible for approving Pull Requests, specifically for
+  top-level content of the repository
+* Chairs may additionally perform any actions of technical leads as needed,
+  especially serving as the Security TAG leadership representative to a project.
 
 ## Role of technical leads
 
@@ -126,7 +122,7 @@ After a [Chair](#role-of-chairs) finishes their term, they transition into a
 role of [Chair Emeritus](#role-of-chair-emeriti). This allows previous Chairs to
 continue to chime in and provide valuable context and contributions to the TAG.
 A [Chair Emeritus](#role-of-chair-emeriti) can assume a role of a [technical
-lead](#roles-of-technical-leads), but in doing so, must be active in
+lead](#role-of-technical-leads), but in doing so, must be active in
 communicating with the co-chairs and technical leads (i.e. participating in the
 chair/TL slack and meetings). A Chair Emeritus has the same permissions/access
 as technical leads.
@@ -159,12 +155,13 @@ given the OWNER role of the directory or sub-directory along with 1 other
 nominated individual to ensure continuity in review and ongoing support of
 the project.
 
-  The nomination is typically open for a week (but may be shorter with LGTM
+  1. The nomination is typically open for a week (but may be shorter with LGTM
   of at least two Chairs).
   1. The issue is updated with the assignment of the project lead as "assignee"
   alongside the TAG Leadership member.
-  1. Project Leads will be given the OWNER role of the directory or sub-directory
-  for their team's activities in order to empower merge/approve.
+  1. Project Leads will be given the OWNER role of the directory or
+  sub-directory for their team's activities in order to empower
+  merge/approve.
 
 This role may be subject to [lead rotations](#lead-rotations).
 
@@ -229,7 +226,6 @@ Examples are:
 
 ## Role of Team Leads
 
-
 Team Leads lead larger streams of work that require sustained effort and
 coordination and remain ongoing.
 
@@ -291,10 +287,9 @@ role for some time informally, then proposed as an on-going role by Pull Request
 which must be approved by a majority of Chairs.  Process clarifications are
 welcome and PRs can be approved by any single Chair.
 
-
 ### Security assessment facilitator
 
-[Security Reviews](/assessments) are part of the ongoing work of the group
+[Security Reviews](/community/assessments) are part of the ongoing work of the group
 and led by a security assessment facilitator (referred to in the rest of this
 sub-section as a facilitator). The facilitator is responsible for:
 
@@ -318,7 +313,7 @@ community [via the `#tag-security`
 channel](https://cloud-native.slack.com/archives/CDJ7MLT8S)), and issue a
 call/request for reviewers (i.e. a single security assessment lead, and at
 least two additional security reviewers), and ensuring all reviewers [read the
-conflict of interest disclosure](../assessments/guide/security-reviewer.md) and
+conflict of interest disclosure](/community/assessments/guide/security-reviewer.md) and
 sign-off on it in the GitHub ticket itself.
 
 From this point forward, the security assessment lead is the primary
@@ -368,6 +363,7 @@ goals, the meeting facilitator has the following responsibilities:
 
 Effective facilitation includes (but is not limited to) the following
 activities:
+
 * Setting the agenda for meetings.
 * Extending discussion via asynchronous communication to be inclusive of
   members who cannot attend a specific meeting time.
@@ -391,7 +387,7 @@ One or more of the following:
 Any member who meets the above qualifications is encouraged to add themselves to
 the [list of people in this role](/.github/settings.yml).
 
-### Meeting scribe(s)
+### Meeting scribe
 
 Each meeting must have at a minimal one scribe and preferable with two.
 
@@ -407,7 +403,6 @@ Scribe is expected to perform the following:
 * Add links to issues being discussed if not already in Agenda.
 * Open new issues to track action items from meeting.
 
-
 ### Triage team
 
 All members are expected to review Pull Requests (PRs), comment on issues, and
@@ -435,7 +430,7 @@ Some ongoing projects may have teams where members are identified for additional
 roles and may be required to have specific expertise. For visibility, these
 additional project roles are listed below:
 
-* [Security Reviewers](../assessments/guide/security-reviewer.md)
+* [Security Reviewers](/community/assessments/guide/security-reviewer.md)
 
 ## Lead rotations
 
diff --git a/governance/tools.md b/governance/tools.md
deleted file mode 100644
index 2c51dc5b8..000000000
--- a/governance/tools.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# Tools
-
-This document contains a set of tools that will be useful to security reviewers
-and project leads. This is not an endorsement of any vendor or open source
-project, rather a collection of what has been useful to individuals to share
-helpful suggestions to others in the group.
-
-## Document conversion
-
-Documents, such as [self-assessments] are sometimes initially drafted in a
-Google doc, which facilitates discussion. At the end of the review, the
-documents needs to be converted to markdown so that they can be added to this
-GitHub repository.
-
-<!-- cSpell:ignore Pandoc -->
-List of tools:
-
-- [Pandoc](https://pandoc.org/demos.html): Check example in this link to convert
-`docx` to `markdown`
-- [Google Docs extension: docs-to-markdown](https://workspace.google.com/marketplace/app/docs_to_markdown/700168918607)
diff --git a/policy-wg-merging.md b/policy-wg-merging.md
deleted file mode 100644
index 0f595fd0e..000000000
--- a/policy-wg-merging.md
+++ /dev/null
@@ -1,23 +0,0 @@
-The Policy WG merged with SAFE WG on Aug 10, 2018, and together submitted SAFE WG proposal to CNCF TOC
-
-This document illustrates the proposed CNCF Policy WG's key objects and deliverables, and the way to forge ahead with SAFE WG as a unified CNCF level WG to avoid unnecessary overlap and concentrate resources.
-
-CNCF Policy WG Proposal
-=======================
-
-Overview: https://docs.google.com/document/d/1KSGODwPSzusENZ2vaX3sw81b7M39mgmESaYnwZi53dQ/edit?usp=sharing
-
-Key Deliverables
-================
-
-- Cloud Native Policy Architecture White Paper
-- Container Policy Interface implementations
-- Various feature requests to projects like kubernetes, opa, istio, spifee, and more.
-
-Way forward on merging with SAFE WG
-===================================
-
-1. Extend the original scope to include policy, such as security oriented policies (RBAC, network, Auth, ...) and resource oriented policies (resource manager, quota, scheduling, topology, ...)
-2. Extend the interested parties to include Policy WG key participants.
-3. Extend the deliverables to include Policy WG deliverables: a new scoped white paper on security and policy, cpi development/discussion, and upstream project feedback/feature request.
-4. WG rename after official status to reflect the new scope and deliverables.
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
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/roadmap.md b/roadmap.md
deleted file mode 100644
index ba31fc888..000000000
--- a/roadmap.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# Security TAG Roadmap
-
-* [Overview](#overview)
-* [Details](#details)
-* [Upcoming](#upcoming)
-  * [Ongoing efforts](#ongoing-efforts)
-* [Completed](completed)
-
-## Overview
-Note:  TAG-Security was rebranded from SAFE working group. The below roadmap
-includes SAFE WG and TAG-Security in its timeline.
-
-|     | <i> #2 Discover </i>| #3 Describe | #4 Identify
-| --- | --- | --- | --- |
-| Artifacts | <i> Personas<br/>Use Cases<br/>Categories </i> | Standards<br/>Common Definitions<br/>Block Architecture | Catalog Projects<br/>Fill in Boxes<br/>Identify Gaps
-| Topics | <i> Presentations<br/>TAG members & guests </i> | Standards in Practice<br/>Real World Systems Architecture | Platforms & Products<br/>Tools & Libraries
-
-## Details
-
-1. **Charter** the SAFE Working Group. Draft vision, process and initial members
-   (done, see below)
-2. **Discover** (Completed)
-   * Explore the problem space of the working group
-   * Investigating what is happening in the community today with respect to security for cloud native applications and infrastructure
-   * [Presentations](issues?utf8=%E2%9C%93&q=is%3Aclosed+is%3Aissue+label%3Ausecase-presentation+) from members & guests
-   * Describe [personas & use cases](usecase-personas/)
-   * Draft a picture or set of categories that will serve as a starting point for an evaluation framework
-   * Solicit real world use cases and practices (and compensating controls) for projects
-3. **Describe** (in progress)
-   * Define the terminology used in the output documents, and in the community
-   * Describe the current state (map) of cloud native security, which might include:
-      * existing standards
-      * existing open source, and proprietary, solutions
-      * common patterns in use today for system that works for cloud native apps. For example:
-        * Extract end-to-end view of secure access, and
-        * Common layering or a block architecture
-4. **Identify** existing security components in CNCF and projects in the CNCF landscape and catalog
-   * Identify gaps and make recommendations to the community and TOC
-   * Continually monitor the viability of the existing projects and update the landscape document
-   * Document and disseminate best practices (provide training?)
-
-## Upcoming
-
-TAG-Security strives to perform annual planning and quarterly reviews of our
-roadmap plans.  The Roadmap planning project board for each annum is a live
-board and is continually updated.  Boards may have cards added which indicate
-early concepts or needs for discovery, prior to become proposals or projects.
-
-| Year | Board Link |
-| --- | --- |
-| 2021-2022 | [RoadMap Planning Board](https://github.com/cncf/tag-security/projects/4) |
-
-### Ongoing efforts
-
-TAG-Security maintains a few activities as regular business.  Boards tracking
-these items linked below.
-
-| Effort | Board Link | Description |
-| --- | --- | -- |
-| CNCF project security reviews | [Security Review Queue](https://github.com/cncf/tag-security/projects/2) | This board is used to manage upcoming and current security reviews and security review related activities. |
-| TAG-Security Projects | [Project Tracking Board](https://github.com/cncf/tag-security/projects/1) | This board is used to manage upcoming proposals (backlog) and ongoing projects. |
-| Issue Triage | [Triage Board](https://github.com/cncf/tag-security/projects/3) | This board is used to assist the Triage team in managing the queue of issues. |
-
-
-## Completed
-
-|   Milestone  | Date | Action
-| --- | --- | --- |
-| First Community Translation | 27 Feb 2021 | [Chinese translation of Whitepaper](https://github.com/cncf/tag-security/pull/471) |
-| Security Assessments => Reviews | 23 Feb 2021 | Retrospective resulted in [process updates](https://github.com/cncf/tag-security/pull/488) |
-| APAC meetings start | 1 Feb 2021 | [Regular meeting time added to README](https://github.com/cncf/tag-security/pull/518)
-| Expanded to 5 Tech Leads | 13 Jan 2021 | [TOC Approves](https://lists.cncf.io/g/cncf-toc/topic/79052801#5599) [@ashutosh-narkar](https://github.com/ashutosh-narkar), [@achetal01](https://github.com/achetal01), [@anvega](https://github.com/anvega) |
-| Cloud Native Security Whitepaper v1 | 18 Nov 2020 | [Markdown source and images in repo](https://github.com/cncf/tag-security/pull/452) |
-| First five security assessments | 21 Oct 2020 | [In-toto, OPA, SPIFFE/SPIRE, Harbor, Keycloak](https://github.com/cncf/tag-security/issues/167) |
-| First chair rotation | 15 Sep 2020 | [TOC approves](https://lists.cncf.io/g/cncf-toc/topic/77001316#5303) [@TheFoxAtWork](https://github.com/TheFoxAtWork) with new [chair proposal process](https://github.com/cncf/tag-security/pull/419/files)
-| DoD Kubernetes/Container Security controls proposed | 26 Jun 2020 | LF collaboration with US DoD [merged to DoD repo](https://repo1.dso.mil/dsawg-devsecops/kubernetes-srg/k8-srg-artifacts/-/tree/master/linuxfoundation) |
-| First Tech Leads  | 25 Feb 2020 | [TOC approves](https://lists.cncf.io/g/cncf-toc/topic/71341283#4198) [@lumjjb](https://github.com/lumjjb) [@TheFoxAtWork](https://github.com/TheFoxAtWork)  [@JustinCappos](https://github.com/JustinCappos) |
-| Security Assessment intake process | 7 Jan 2020 | [Intake process and prioritization](https://github.com/cncf/tag-security/pull/296) |
-| First Cloud Native Security Day | 19 Nov 2019 | [Event](https://events19.linuxfoundation.org/events/cloud-native-security-day-2019/) organized by [@mfdii and @TheFoxAtWork](https://github.com/cncf/tag-security/issues/209) |
-| Software supply chain catalog  | 14 Nov 2019 | [Catalog](https://github.com/cncf/tag-security/pull/284) |
-| Updated personas & use cases | 23 Sept 2019 | [Added platform implementer](https://github.com/cncf/tag-security/pull/246)
-| Policy formal verification overview | 10 Sept 2019 | [Documentation](https://github.com/cncf/tag-security/pull/242)
-| First Security Assessment | May 2019 | [In-toto](https://github.com/cncf/tag-security/pull/202)  |
-| Updated Charter and Governance ratified by CNCF TOC |  7 May 2019 | [New repo](https://github.com/cncf/tag-security/tree/main/governance) |
-| First cut security audit guidelines  | 2 May 2019 | [Guidelines](https://github.com/cncf/tag-security/pull/125) |
-| Moved SAFE WG to CNCF  | 15 Apr 2019 | [Repo rename](https://github.com/cncf/tag-security/pull/148) |
-| CNCF WG proposal | 21 Aug 2018 | [CNCF TAG-Security charter and roles](https://github.com/cncf/toc/pull/146) |
-| Policy WG merged | 10 Aug 2018 | [Merging policy WG](https://github.com/cncf/tag-security/blob/main/policy-wg-merging.md)  |
-| First KubeCon Presentations | 2-4 May 2018 | [Intro](https://kccnceu18.sched.com/event/ENw3/safe-wg-intro-jeyappragash-j-j-padmeio-ray-colline-google-any-skill-level) and [deep dive](https://kccnceu18.sched.com/event/ENw5/safe-wg-deep-dive-ray-colline-google-intermediate-skill-level) |
-| Personas & use cases | 20 Apr 2018 | [Shared doc into repo markdown](https://github.com/cncf/tag-security/pull/16)
-| Initial Commit for SAFE repo | 13 Mar 2018 | [First commit](https://github.com/cncf/tag-security/commit/fe999bd637456ade5e6cc8866d0db4107a0d9778) |
-| Informal discussions at Kubecon Austin | Dec 2017 | Meeting with CNCF community and gathering feedback |
diff --git a/supply-chain-security/README.md b/supply-chain-security/README.md
deleted file mode 100644
index f0df0cc8b..000000000
--- a/supply-chain-security/README.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Software Supply Chain
-
-Supply chain compromises are a powerful attack vector. In cloud native
-deployments everything is software-defined, so there is increased risk when
-there are vulnerabilities in this area. If an attacker controls the supply
-chain, they can potentially reconfigure anything in an insecure way.
-
-## What are supply chain vulnerabilities and their implications?
-
-The [Catalog of Supply Chain Compromises](./compromises) provides real-world
-examples that help raise awareness and provide detailed information that
-let's us understand attack vectors and consider how to mitigate potential
-risk.
-
-## On mitigating vulnerabilities
-
-There is on-going work to establish best practices in this area. The list of
-[types of supply chain compromises](./compromises/compromise-definitions.md)
-in the [catalog of supply chain compromises](./compromises) suggests some
-mitigation techniques for the more well understood categories.
-
-## Supply chain security paper
-
-STAG (Security Technical Advisory Group) has put work into a comprehensive
-software supply chain paper highlighting best practices for high and medium risk
-environments. Please check out
-[the paper](./supply-chain-security-paper/sscsp.md)
-and corollary
-[secure supply chain assessment document](./supply-chain-security-paper/secure-supply-chain-assessment.md)
-to learn more.
-
-For information about contributing to the document or providing feedback, please
-refer to the [README](./supply-chain-security-paper/README.md).
diff --git a/website/Makefile b/website/Makefile
index b5c13d03d..051a99512 100644
--- a/website/Makefile
+++ b/website/Makefile
@@ -3,14 +3,14 @@ deps:
 
 	# Move select content from the root level into the website directory.
 	rsync -avv ../ root/ \
-	--include='assessments' --include='assessments/**' \
 	--include='governance' --include='governance/**' \
-	--include='publications' --include='publications/**' \
+	--include='community/publications' --include='community/publications/**' \
 	--include='community' --include='community/**' \
 	--include='*.md' --exclude='*'
 
 	# Move over content such as graphics and logos
-	rsync -av '../design/' 'static/design/' --exclude='#*'
+	mkdir -p static/community/resources/design/
+	rsync -av '../community/resources/design/' 'static/community/resources/design/' --exclude='#*'
 
 	# Update all imported markdown files to work as standalone hugo pages (except READMEs, see below)
 	# sed command is configured for the Netlify ubuntu env
@@ -76,4 +76,4 @@ clean:
 	@git clean -f .
 	@rm -rf public resource
 	@find root/* -type f ! -name '*.gitkeep' -print0 | xargs -0 rm -v
-	@echo "Finished removing anything residual"
+	@echo "Finished removing anything residual"
\ No newline at end of file
diff --git a/website/content/blog/cnsc-2024-takeaways.md b/website/content/blog/cnsc-2024-takeaways.md
new file mode 100644
index 000000000..8c2bee9c0
--- /dev/null
+++ b/website/content/blog/cnsc-2024-takeaways.md
@@ -0,0 +1,105 @@
+---
+title:  "Securing the Cloud: Insights from CloudNativeSecurityCon 2024"
+date:  2024-07-10T13:30:00-04:00
+author: Shlomo Zalman Heigh
+---
+
+I recently had the pleasure of attending and speaking at the CNCF's
+[CloudNativeSecurityCon 2024](https://events.linuxfoundation.org/cloudnativesecuritycon-north-america/)
+in Seattle, WA. The conference brought together security professionals,
+developers, and industry experts to discuss the latest trends and advancements
+in cloud native security. The keynotes, breakout sessions, and networking
+opportunities provided valuable insights into the evolving landscape of security
+practices. Here are some key takeaways I gathered from the event:
+
+## Industry Progress in Supply Chain Security
+
+At the conference, we witnessed significant advancements in supply chain
+security. Three notable projects stood out to me: SLSA, GUAC, and VEX.
+
+- **SLSA and GUAC**: Both SLSA and GUAC aim to improve transparency and trust in
+software supply chains. By defining different maturity levels of supply chain
+security (SLSA), and providing a graph to visualize and reason about it (GUAC),
+they helps organizations make informed decisions about the components they use.
+It was clear to me that both SLSA and GUAC are gaining tremendous traction in
+the industry, and their adoption will surely enhance visibility into security
+posture across the software supply chain.
+
+- **VEX (Vulnerability Exploitability eXchange)**: VEX addresses the
+overwhelming number of vulnerabilities detected during container scans. It aims
+to allow teams to prioritize and handle vulnerabilities more effectively by
+knowing which ones are more likely to be exploited and which should be treated
+as false positives. There are a few implementations of the VEX standard, and
+there were several talks at the conference discussing how to integrate VEX into
+existing security workflows. We'll cover this more a bit later in this post.
+
+## Trends in Identity and Workload Security
+
+The industry is shifting away from long-lived credentials toward workload
+identity. SPIFFE (Secure Production Identity Framework For Everyone) has gained
+prominence as a standard for workload identity. This approach enhances security
+by ensuring that services can only access resources they are explicitly
+authorized to use, without the need for long-lived credentials which are
+prone to leakage.
+
+[Session link](https://sched.co/1dCWN)
+
+## Lighter Systems: Operators Over Sidecars
+
+Traditionally, sidecars have been used to enhance container functionality, and
+provide authentication between services. However, the trend is moving toward
+lighter systems like operators, which don't require additional resources for
+each pod and therefore scale more efficiently. In particular, we saw Istio's new
+Ambient Mode demoed in the keynote by Lin Sun. This feature is still in beta,
+and you can learn more on the
+[Istio blog](https://istio.io/latest/blog/2024/ambient-reaches-beta/).
+
+[Keynote link](https://sched.co/1dCVF)
+
+## University Open Source Centers and Student Involvement
+
+One of my favorite breakout sessions was given by two students from Rensselaer
+Polytechnic Institute, Ben Smith-Foley and Sam Begin. They discussed how
+University Open Source Centers, such as RCOS (Rensselaer Center for Open
+Source), provide students with valuable opportunities to learn and gain
+real-world experience. These centers bridge the gap between classroom learning
+and practical skills. Students can contribute to open-source projects, document
+their processes, and tackle "good-first-issue" tasks. I always enjoy hearing
+about initiatives that encourage student involvement in open source, and I was
+inspired by the work these students are doing and hope to see more universities
+adopt similar programs which are beneficial for both students and the
+open-source community.
+
+[Session link](https://sched.co/1dCUW)
+
+## VEX: Automated Vulnerability Prioritization
+
+As mentioned earlier, VEX has been gaining traction as a way to prioritize
+vulnerabilities detected during container scans. I had the privilege of
+delivering a presentation on automated generation of VEX documents using
+Kubescape along with Ben Hirschberg, CTO of [Armo](https://www.armosec.io/). We
+discussed how [Kubescape](https://kubescape.io/) can be used to generate VEX
+documents through runtime analysis of containers in Kubernetes, and how we
+developed a new
+[GitHub Action](https://github.com/kubescape/generate-vex-action) to automate
+this process.
+
+[Session link](https://sched.co/1dCWE)
+
+## Conclusion
+
+There were many more valuable insights and takeaways from
+CloudNativeSecurityCon, and I encourage you to explore the conference schedule
+and watch the recorded sessions once they are available on the
+[CNCF YouTube channel](https://www.youtube.com/@cncf). I'm excited to see
+the continued progress in cloud native security and look forward to attending
+future events to learn more about the latest trends and advancements in the
+industry.
+
+## About the Author
+
+Shlomo Heigh is a Senior Software Engineer at CyberArk, where he maintains the
+[Conjur](https://www.conjur.org/) open source secrets manager. He is a
+contributor to the CNCF's TAG Security and an OWASP chapter leader. You can find
+him on [LinkedIn](https://www.linkedin.com/in/szheigh) and
+[GitHub](https://github.com/szh).
diff --git a/website/content/blog/historical-presentations-June-24.md b/website/content/blog/historical-presentations-June-24.md
new file mode 100644
index 000000000..547c40582
--- /dev/null
+++ b/website/content/blog/historical-presentations-June-24.md
@@ -0,0 +1,53 @@
+---
+title:  "Historical Presentations on TAG Security"
+date:   2024-06-25 09:00:00 -0700
+author: Eddie Knight 
+---
+
+Prior to now, TAG Security has kept a list of time-based events and associated links. The tracking was previously maintained by several attentive TAG members, and served as a good way to keep folks aware and involved.
+
+As part of the website redesign and the reorganization of the main TAG git repo, we've decided not to store a centralized list of non-recurring events.
+
+But we realized that there were some gems in there that were too good to lose! Below is a list of presentations that you can view to learn more about the history of our community and its contributors.
+
+We may find a tidy place to track this in the future, but for now the blog is a safe place to make this list available.
+
+Enjoy!
+
+## TAG talks
+
+- [CNCF TAG-Security Intro](https://kccnceu19.sched.com/event/OB0K/intro-cncf-security-tag-sarah-allen-jeyappragash-jeyakeerthi-tetrateio)
+\-  [slides](https://docs.google.com/presentation/d/1KE2tDDOeEOXQLF6hSrAuQLn4z25O_jeHIeAVE4CB-VI/edit#slide=id.gc6fa3c898_0_70)
+| [video](https://www.youtube.com/watch?v=XD89-v3oWPE)
+
+- [CNCF TAG-Security Deep Dive](https://kccnceu19.sched.com/event/Oscd/deep-dive-cncf-security-tag-justin-cappos-new-york-university-zhipeng-huang-huawei)
+\- [slides](https://docs.google.com/presentation/d/18nzXspPuRDRKfGUSI1ogFHmUOP_XHS78nz-0uTG9Ogs/edit?usp=sharing)
+| [video](https://www.youtube.com/watch?v=EF3nl80kpm4)
+- [Inside CNCF Project Security Reviews](https://kccnceu19.sched.com/event/MPdf/inside-the-cncf-project-security-reviews-justin-cormack-docker)
+\- [video](https://www.youtube.com/watch?v=0BkKpsrUo5k)
+
+## Misc security-related talks
+
+- [Intro: TUF/Notary](https://docs.google.com/presentation/d/1Mp4pSMEvZIv0qo6wBWm-4vM6CZ-0IXimpq8zD3iTH0Q/edit#slide=id.g5a645bebe8_0_921)
+\- [video](https://www.youtube.com/watch?v=gIFRQObHbZk)
+- [Deep Dive: TUF/Notary](https://kccnceu19.sched.com/event/MPkF/deep-dive-tuf-notary-justin-cappos-lukas-puehringer-nyu)
+\- [video](https://www.youtube.com/watch?v=PSujE86JvBk)
+- [Intro: SPIFFE](https://kccnceu19.sched.com/event/MPib/intro-spiffe-emiliano-bernbaum-scott-emmons-scytale)
+\- [video](https://www.youtube.com/watch?v=Rx6PMptyEtg)
+- [Deep Dive: SPIFFE](https://kccnceu19.sched.com/event/MPk9/deep-dive-spiffe-scott-emmons-emiliano-bernbaum-scytale)
+\- [video](https://www.youtube.com/watch?v=OHiPsqT1gcI)
+- [Intro: Open Policy Agent](https://kccnceu19.sched.com/event/MPiM/intro-open-policy-agent-rita-zhang-microsoft-max-smythe-google)
+\- [video](https://www.youtube.com/watch?v=Yup1FUc2Qn0)
+- [Deep Dive: Open Policy Agent](https://kccnceu19.sched.com/event/MPk0/deep-dive-open-policy-agent-torin-sandall-tim-hinrichs-styra)
+\- [video](https://www.youtube.com/watch?v=n94_FNhuzy4)
+- [Secrets Store CSI Driver-Bring Your Own Enterprise Secrets Store to K8s](https://kccnceu19.sched.com/event/MPdZ/secrets-store-csi-driver-bring-your-own-enterprise-secrets-store-to-k8s-rita-zhang-microsoft-anubhav-mishra-hashicorp)
+\- [video](https://www.youtube.com/watch?v=bIC4kLnrKN0)
+- [Protecting the Data Lake with OPA](https://sched.co/MPdu)
+\- [slides](https://drive.google.com/file/d/1NVKn88EoRAzi_Kd5KGPfOjd6fZpLhjJE/view?usp=sharing)
+| [video](https://www.youtube.com/watch?v=9m4FymEvOqM)
+- [Securing Kubernetes with Trusted Platform Module (TPM)](https://kccnceu19.sched.com/event/MPdN/securing-kubernetes-with-trusted-platform-module-tpm-alex-tcherniakhovski-andrew-lytvynov-google)
+\- [slides](https://static.sched.com/hosted_files/kccnceu19/a9/Securing%20Kubernetes%20with%20Trusted%20Platform%20Module.pdf)
+| [video](https://www.youtube.com/watch?v=_kxmkI8Kc8Y)
+- [Uber x Security: Why and How We Built Our Workload Identity Platform](https://kccnceu19.sched.com/event/MPe6)
+\- [slides](https://static.sched.com/hosted_files/kccnceu19/bf/slides-julian-feldman.pdf)
+| [video](https://www.youtube.com/watch?v=JKkq60DvPBw)
diff --git a/website/content/blog/website-relaunch-2024.md b/website/content/blog/website-relaunch-2024.md
new file mode 100644
index 000000000..295a31725
--- /dev/null
+++ b/website/content/blog/website-relaunch-2024.md
@@ -0,0 +1,33 @@
+---
+title:  "Website Re-Launch at CNSC '24"
+date:   2024-06-26 09:00:00 -0700
+author: Eddie Knight 
+---
+
+A lot is happening in the world of TAG Security recently! Most notably, this website is re-launching with a whole new set of content— thanks to contributions from the TAG leads and the special attention paid by TAG members **Brandt Keller** and **Marco De Benedictis**.
+
+At the time of this publication, a large portion of the cloud native security community is gathered in Seattle for CloudNativeSecurityCon North America, where Chris Aniszczyk is on stage calling the community to a higher standard— to "Grow up!"
+
+> It is our responsibility, as a community, to ensure there are safe and secure practices for the cloud native ecosystem, so we can continue to run the majority of the world’s workloads. - Chris Aniszczyk
+
+Our community has done a great deal for the growth of open source security, along with others across the Linux Foundation and beyond, and it's worth taking a moment to celebrate the wins.
+
+Members and sponsors of CNCF can be proud that their contributions have gone toward more than 30 comprehensive security audits of projects in our ecosystem. TAG Security contributors, including project maintainers, have provided over 35 security [assessments](/community/assessments) that can be viewed publicly.
+
+In addition to those assessments and the industry-shaping publications released by TAG Security, we have also seen CNCF projects dramatically improve their security hygiene after engaging with our initiatives. Based on historical metrics that can easily be viewed on [CLOMonitor](https://clomonitor.io), projects that participate in the Cloud Native Security Slam perform _significantly_ higher month-over-month on metrics that are statistically correlated to reductions in the rate of CVEs.
+
+Still, the open source community— including CNCF— have gaps to address. You should have heard of the Polyfill compromise by now... but what you may not know is that concerns were raised across the community months before the attack began. This, `xz`, and too many other supply chain attacks have been possible in part because the community of end-users has failed to _effectively_ support project maintainers.
+
+To be effective, we need to constantly try new approaches where we have previously failed.
+
+Here in TAG Security we aim to lead by example. We hope to create an open and encouraging space for folks from across the open source community to not only improve their own cloud native security, but also support project maintainers through the sharing of knowledge and targeted improvement initiatives.
+
+In an effort to increase our effectiveness, we have recently begun a concerted effort to increase the quality of our communications and publications. The website redesign is part of that effort.
+
+If you follow along with our work in the coming weeks, you will also see:
+
+1. A reorganization to the GitHub repo, with the directory structure being used to better organize content according to the [working group](/community) that manages it.
+2. A clearer criteria for publishing TAG Security [publications](/publications/), with an emphasis on facilitating a clear review process that holds all content to a high standard.
+3. A new process for regularly featuring opinion pieces and announcements from the community through this blog portal.
+
+We're excited to continue in our role as CNCF's Technical Advisory Group for Security, and we hope you're excited to [join us](/#meeting-information)!
diff --git a/website/layouts/_default/baseof.html b/website/layouts/_default/baseof.html
index b240def13..ef3d45fe2 100644
--- a/website/layouts/_default/baseof.html
+++ b/website/layouts/_default/baseof.html
@@ -21,7 +21,7 @@
             {{ partial "toc.html" . }}
           </aside>
           <main class="col-12 col-md-9 col-xl-7 pl-md-5" role="main">
-            {{ partial "under-construction-tmp" }}
+            <!-- {{ partial "under-construction-tmp" }} -->
             {{ if not .Site.Params.ui.breadcrumb_disable }}{{ partial "breadcrumb.html" . }}{{ end }}
             {{ with .Params.Category}}<div class="category"><i class="{{ lower . }}"></i>{{ upper . }}</div>{{ end }}
             {{ block "main" . }}{{ end }}
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 @@ <h1 class="thin">{{ .Title }}</h1>
 
 		var newUrl = baseUrl + "?" + urlParams.toString();
 		// Update the browser history (optional)
-		window.history.pushState({}, null, newUrl);
+		history.replaceState(null, '', newUrl);
 	}
 	</script>
 	
diff --git a/website/netlify.toml b/website/netlify.toml
index dff064dd4..a06d774ac 100644
--- a/website/netlify.toml
+++ b/website/netlify.toml
@@ -6,7 +6,7 @@ ignore = "exit 1"
 
 [build.environment]
 NODE_VERSION = "18.16.1"
-HUGO_VERSION = "0.115.2"
+HUGO_VERSION = "0.128.0"
 
 [context.production.environment]
 HUGO_ENV = "production"
diff --git a/website/package-lock.json b/website/package-lock.json
index 4fcf435a6..3a00ccb18 100644
--- a/website/package-lock.json
+++ b/website/package-lock.json
@@ -4,10 +4,9 @@
   "requires": true,
   "packages": {
     "": {
-      "name": "website",
       "dependencies": {
         "autoprefixer": "^10.4.0",
-        "hugo-extended": "^0.115.2",
+        "hugo-extended": "^0.127.0",
         "postcss": "^8.4.31",
         "postcss-cli": "^9.1.0"
       }
@@ -1000,9 +999,9 @@
       }
     },
     "node_modules/hugo-extended": {
-      "version": "0.115.4",
-      "resolved": "https://registry.npmjs.org/hugo-extended/-/hugo-extended-0.115.4.tgz",
-      "integrity": "sha512-sZQ+melq3ZDUeKhOoz/ElpS/5LA77F2z8RllGPsi/OPt3otexMSucunTvZzjLuoebaHW/g11DgMmlx1CPgYvLA==",
+      "version": "0.127.0",
+      "resolved": "https://registry.npmjs.org/hugo-extended/-/hugo-extended-0.127.0.tgz",
+      "integrity": "sha512-TDjizLf8cUpkRPkHXeDq3rZJKSAUdguV7KPddOZrclNcnL1QQh/9BgKddCZP0+4/nolPOb6GI+2LhIehfjrUHw==",
       "hasInstallScript": true,
       "dependencies": {
         "careful-downloader": "^3.0.0",
@@ -1014,7 +1013,7 @@
         "hugo-extended": "lib/cli.js"
       },
       "engines": {
-        "node": ">=14.14"
+        "node": ">=16.14"
       }
     },
     "node_modules/ieee754": {
diff --git a/website/package.json b/website/package.json
index ad98809ca..26a5f7175 100644
--- a/website/package.json
+++ b/website/package.json
@@ -6,7 +6,7 @@
   },
   "dependencies": {
     "autoprefixer": "^10.4.0",
-    "hugo-extended": "^0.115.2",
+    "hugo-extended": "^0.127.0",
     "postcss": "^8.4.31",
     "postcss-cli": "^9.1.0"
   }
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/_table.scss b/website/themes/docsy/assets/scss/_table.scss
new file mode 100644
index 000000000..c23d0acdb
--- /dev/null
+++ b/website/themes/docsy/assets/scss/_table.scss
@@ -0,0 +1,5 @@
+#tag-security-publications ~ table {
+	td:nth-child(4) {
+		white-space: nowrap;
+	}
+}
\ 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 4a3c44610..f85d894ba 100644
--- a/website/themes/docsy/assets/scss/main.scss
+++ b/website/themes/docsy/assets/scss/main.scss
@@ -26,6 +26,8 @@
 @import "blocks/blocks";
 @import "section-index";
 @import "pageinfo";
+@import "table";
+@import "logo";
 
 @if $td-enable-google-fonts {
     @import url($web-font-path);
diff --git a/website/themes/docsy/userguide/package-lock.json b/website/themes/docsy/userguide/package-lock.json
index 88f75f003..d4adc3d85 100644
--- a/website/themes/docsy/userguide/package-lock.json
+++ b/website/themes/docsy/userguide/package-lock.json
@@ -67,12 +67,23 @@
       "dev": true
     },
     "braces": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
-      "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
+      "version": "3.0.3",
+      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz",
+      "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==",
       "dev": true,
       "requires": {
-        "fill-range": "^7.0.1"
+        "fill-range": "^7.1.1"
+      },
+      "dependencies": {
+        "fill-range": {
+          "version": "7.1.1",
+          "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz",
+          "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==",
+          "dev": true,
+          "requires": {
+            "to-regex-range": "^5.0.1"
+          }
+        }
       }
     },
     "browserslist": {
@@ -175,15 +186,6 @@
         "reusify": "^1.0.4"
       }
     },
-    "fill-range": {
-      "version": "7.0.1",
-      "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
-      "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
-      "dev": true,
-      "requires": {
-        "to-regex-range": "^5.0.1"
-      }
-    },
     "fraction.js": {
       "version": "4.3.6",
       "resolved": "https://registry.npmjs.org/fraction.js/-/fraction.js-4.3.6.tgz",