SAF Site Map (WIP)

[ChrisHinchey]

Below is a draft of the site map that is up for discussion. I have provided examples of what the URLs would look like.

SAF Components:

• Applications   /apps/{application_name}/{docs,installation,faq,downloads,apis}
  • Heimdall Lite   saf.mitre.org/apps/heimdall-lite/…
  • Heimdall Server
  • Vulcan   saf.mitre.org/apps/vulcan/...
  • SAF CLI
• Specifications   /spec/{spec_name}/{docs,usage,faq,downloads}
  • Heimdall Data Format   saf.mitre.org/spec/heimdall-data-format/...
    • Inspec JS
• Libraries   /libs/{lib_name}/{docs,installation,faq,downloads}
  • TS Inspec Objects
  • Harden
  • Validation
  • Inspec JS   saf.mitre.org/libs/inspec-js/...
  • HDF Converters
• APIs   /apis/{lib_name}/{docs,...}
  • Heimdall Server Open API (Nest JS Backend)
  • Vulcan Open API (Rails)   saf.mitre.org/apis/vulcan-open-api/...
  • eMasser Open API
• Tools/Scripts
• Integration   /integrations/{lib_name}/{docs,...}
  • GitHub Action
  • Lambda Function   saf.mitre.org/integrations/lambda-function/...
    • Inspec Runner
    • Heimdall Pusher
• External Projects
  • Progress/Chef
    • Inspec
    • Chef Workstation
  • CINC
    • CINC Auditor
    • CINC Workstation
• Technologies Used
  • Serverless.com Framework (Used in lambda functions)
  • Terraform
  • Puppet
  • Ansible
  • Chef Infra
  • Javascript
  • Typescript
  • OpenSCAP
  • SCAP/Oval/XCCDF

[Amndeep7]

Do Heimdall lite and server require different pages? They're the same codebase, but server just has extra stuff tacked on.

Should docs/installation/whatever be on different endpoints? Or on the same page and locatable via anchors/fragments?

Emasser should be listed as an application? tho I think we're working on subsuming it within the saf cli.

Should the emass api/swagger stuff be listed under specifications as opposed to (or in addition to) apis?

The emass client/library stuff should be listed under libraries - we have an instantiated ruby one that powers emasser and one that i think we're instantiating in js/ts for the saf cli.

Other products that we gotta keep in mind (inspec delta, serverless function (which is nominally separate from the lambda stuff), etc. are mitre, but there are external products as well like that benchmark generator thing we link on the saf site)

Should we have a front-end replacement for https://public.cyber.mil/stigs/downloads/? I know we've had some talk about pulling down and maintaining an internal listing of all the srgs/stigs so why not have a nicer view of looking at them

What is the plan for all of the hardening and validation content (ex. all of the inspec profiles)? Are they only being listed on their respective tabs on the rest of the site? Or is it possible to have more in-depth docs and stuff here (possibly harvested from (and previously standardized on) their respective repos)?

[wdower]

Do Heimdall lite and server require different pages?

We've been moving away from calling it Heimdall Lite vs. Server and have tried to just call it Heimdall (which has multiple ways to deploy). So the site would still be Heimdall Lite, but we want people to just think of the app itself as 'Heimdall'.

Like Amndeep said add the emasser client to the Libraries list (it's the codebase that eMASSer runs on for API calls). Also add GiHub Actions and Docker/Podman to the technologies used; we use those a lot.

We don't need to separate out delta since it's just going to be another part of SAF CLI.

I do think the current site's feature of having some big ol' HARDENING and VALIDATION buttons up top on the navbar is helpful since that's a huge part of what people will go to the site for. Even if we wind up just having all of our current hardening and validation content being contained on the Tools/Scripts page, could we get buttons that link to a filtered version of the page for just hardening/validation?

We also still need pages for Training and Getting Started like the current site has but I think plans for those are in the works, right? And the Blog pages?