• defaults to text based impacts: none,low,medium,high,critical
• uses desc 'sub-section, 'textfor:check,fix,justification,vulnerability discussion`, etc[]
• puts attributes in the inspec.yml file and uses the shared attributes model
• has the ability to remember what attributes have been created already for easy reuse
• uses the supports: <platform> in the inspec.yml
• adds both a single line profile title and a long desc with in the inspec.yml
• correctly populates all the values in the inspec.yml template

Clicking on "Requested Changes" currently does not show anything. For simplicity it may be best to just remove this feature for now.

As you can see here, the side spacing and the footer bound the application area. We seem to have lost that in our pages.

http://coderthemes.com/minton/new-layout-hori/index.html

The devise do-not-reply email currently defaults to [email protected]. We need to make this configurable in the vulcan.yml config file.

One potential way to fix this is by making Devise use the ApplicationMailer and then fixing the ApplicationMailer to get the proper address from vulcan.yml.

This feature was present in the Vulcan alpha, however it has not been ported over to the new vulcan master.

This feature currently duplicates a lot of code out inspec_tools, as part of porting this feature we should de-duplicate all of this code so that we do not have to maintain two instances of this code.

We also need tests for this feature validating that importing SRG's works correctly, as well as verification that all the associated SRG checks imported correctly as well.

Part of the current code used for SRG import: https://github.com/mitre/vulcan/blob/c2d81c40e665a2f88701d373b41a19fdf48f53ca/app/services/CCIAttributes.rb

Code in inspec_tools: https://github.com/mitre/inspec_tools/blob/b5178b1379759e5fa0e6c9769e829bf3df085491/lib/happy_mapper_tools/cci_attributes.rb

Functionally they seem to be the same, in fact most of the files in app/services in the Vulcan alpha app seem to be duplicates from inspec_tools.

Currently there are is no way to upgrade between releases of SRGs. We need to add this ability.

Dragging these to reorder does nothing, the element just returns to its original location once you let go. This also really distracts from the actual thing that you need to do with the controls, which is click on them to edit.

When a datatable pagination is longer than the component it is in, it overflows and causes the datatable to overflow the component.

Steps to reproduce:

• Create a new Project using the Application Server SRG
• Mark it as non-pending
• Click on Actions > Show Controls
• Receive following error

Unsure if this is related to #39 or if this is a separate error since this happens whether you are using the old or new Application SRG.

Create frontend components that allow for management of Users.

SRG's currently have a V- number linked to them. This number is NOT the number that is supposed to be exported when you export an InSpec profile. We still need to figure out what the format is for generating this number, however we don't know what that is yet.

Currently it is not possible to create a STIG Item that addresses multiple SRGs. We also need to handle the case where multiple STIG items are all addressing a single SRG. (So we need a many-to-many table).

Need to add a "Link Item" and "Decompose Item" button to the Show Controls UI.

When the project is finished and approved, the end user should be able to click a button to export the project as a STIG checklist.

Use our inspec 2 checklist code to make this implementation faster.

Heimdal2 has code already written into rails format that might be helpful

Currently no errors show up when users attempt to login with an incorrect username and/or password.

Related to 2 on #70 (comment)

Currently there is a concept of Vendor and Sponsor. In order to simplify logic, it makes sense to rename both these concepts to Organization and allow a Project to belong to a vendor or a Sponsor.

Control IDs that are shown throughout the application are currently not actually STIG Item IDs, they are Vulnerability SRG IDs. These numbers should not be exported when you export a InSpec profile, and they should not be shown in the Show Controls listing.

The current login structure could use reworking, it is broken out into LDAP and User login. We should reconfigure them so users only have 1 login box.

Related to 3 on #70 (comment)

Implementation details: https://ognjen.io/devise-ldap-and-database/

TODO

• Add a Sign In | Registration tab on top of the sign in form.
• Finish actually reimplementing LDAP and Local login to work through this single form
• Redesign Password Reset page as well
• Get user dropdown in the top right actually working properly
• Figure out actually useful text for homepage that will benefit a user who does not fully understand what Vulcan does.
• Add ability to turn local login on or off.

Currently the generated SRG outputs

tag Related SRG: "SRG-APP-000001-AS-000001"

This is supposed to be

tag satisfies: ["SRG-APP-000001-AS-000001", "<SRG #2>", etc]

If you create a new project and go to "Show Controls" and click on a control, it is very unclear that you are not able to edit the control there since a textbox was used to display the text:

Typing in this textbox doesn't work.

If you actually want to edit a control you have to go back to the project page and choose "Edit Controls".

It is generally a bad idea to shell out in order to execute things unless we really have to, and is not very reliable (this didn't work on my system at first due to path issues). We currently shell out multiple times to run inspec commands when packaging a profile. Since we already require Inspec and Inspec is ruby code, it should be possible to call these functions directly.

Examples:

Currently there is no way for users to join different organizations. One way to make this possible would be for users to choose an organization during signup and also allow users to request to join and organization as well as allow organizations to invite users.

It is currently difficult to use the application as a newcomer due to some intricacies with the current role setup. In order to make it easier to use, the following changes should be made:

As an Admin I can:

• See all projects and statuses
• See everything
• Approve anything

Docker build does not allow persistence, and in general fails to build

Currently it is possible to click through the whole "Start new Project" page without selecting any options and inputting any text. At the end no new project is created and no error is shown.

• This would support the idea of creating a vulcan project that doesn't have a base SRG
• The main use case would be for the process of creating an SRG itself

Currently there are a lot of spots where we are manually assigning elements to hashes instead of just plucking them. One example of this is the below code:

  def insert_profile_data(inspec_json)
    inspec_json['name'] = name
    inspec_json['title'] = title
    inspec_json['maintainer'] = maintainer
    inspec_json['copyright'] = copyright
    inspec_json['copyright_email'] = copyright_email
    inspec_json['license'] = license
    inspec_json['summary'] = summary
    inspec_json['version'] = version
    inspec_json
  end

This could be replaced with

  def insert_profile_data(inspec_json)
    inspec_json.merge(
      as_json(only: [:name, :title, :maintainer, :copyright, :copyright_email, :license, :summary, :version])
    )
  end

There are multiple instances where we do this in app/models/project.rb. It may simplify the code significantly if we were to clean these up.

We can ignore the DB existing case for vulcan as long as we do not overwrite the db. which the rake task does check for.

$ docker-compose run web rake db:setup >/dev/null 2>/dev/null
ERROR: Job failed: exit code 1

Something is going wrong with the icon assets in Production mode

Steps to reproduce: Follow the docker deployment instructions.

There should be a concept of "Sensitive" projects which have more limited permissions, and can only be seen by users with the "sensitive" role. There also needs to be the ability to mark projects as sensitive when creating them.

Real issue is it is not possible to tell if the container built, and was started due to logs filling up before that point.

Fix is to redirect to /dev/null, and check the exit code for errors in the CI tools.

Vulcan should have the ability to export and import a project as a csv so users can collaborate and share project data. Also to be able to see the project in the common form.

Currently, vulcan-next has a block of text that provides users with a basic explanation of what Vulcan does. It is currently just filled with lipsum text:

We need some better text for this page.

The user should be able to add controls that are specific for a vulcan project control for the purpose of being able to insert those tags into the finished inspec profile.

Currently the app/assets/javascripts folder contains all external libraries directly dumped into the project. We need to update this to use webpacker and revisit which dependencies you actually need, since a lot of these are no longer supported. Most of the current versions we have are from 2014, jQuery is slightly more up-to-date, that version is from 2016.

https://github.com/mitre/vulcan/tree/fac35d3d3eb4d43101f489de7bd450b26f27e724/app/assets/javascripts

Once this is fixed, need to see if #81 is also resolved.

There are different operating environments that the application needs to operate in. For example, someone running the application on their local machine or inside their application would want less restrictive operation than a centralized installation shared by multiple users. The options that should be configurable are as follows:

• Users (will/will not) be automatically approved
• Access (will/will not) be restricted by role.
  A default role (will/will not) not be set for new users.

Components would replace the concept of Projects and a Project would have many components (Projects are moving "up a level").

An example of this is shown here where each part of the project is broken down into its own component.

Projects can include components in a read-only state.

The Alpha Vulcan had a concept of projects. In new Vulcan we are aiming to have a concept of Components and Projects: #58. In order to do this we need to setup the ability to create Components in the new version, and then port the remaining code required for regular project work as well.

When a user adds a new comment on a control, that comment is not displayed in any meaningful manner to someone viewing the project. In the below photo there is 1 new comment on control V-35150. As a user I have no way of telling this.

Even clicking on the issue doesn't make it clear which have comments and which don't (hint: Applicability has 2 comments):

For some reason the password validation field is not actually working, it is just taking the value of password and ignoring password_confirmation.

Currently the logic for figuring out what users are part of a vendor only looks at what users that vendor or sponsor had at creation time. This means that the only list of users that matters when a user is creating a project is the one at that moment. To make this worse there is no list shown for what users can see a project, so that user can just silently still see all progress on Projects after they have been removed from the team.

Relevant code:
This is where the users are added to the project (on creation):

Currently we have a setting in vulcan.yml for turning Devise email confirmation on and off. We need to add a method to our custom registrations_controller which calls skip_confirmation! if this option is actually enabled.

Instead of modifying the registrations_controller, another potentially acceptable option is to call skip_confirmation! before_create on the user model. This also might be easier to add tests for in the User model spec.