Skip to end of metadata
Go to start of metadata

As per the charge of this group, recommendations are presented here on the following items:

  1. Ranking and Classification of Security Issues
  2. Developer Security Training and Assessment
  3. Tooling for Detection of Security Issues
  4. Public-Facing Security Page
  5. Internal Documentation

Ranking and Classification of Security Issues

After evaluating some of the available ranking systems, it is the recommendation of this working group that we use the Open Web Application Security Project (OWASP) risk rating methodology for ranking security issues:

This methodology uses a simple approach of assigning a value of 0-9 for the "Likelihood" and "Impact" of a particular security issue. These two terms are defined as follows:

  • Likelihood - a rough measure of how likely this particular vulnerability is to be uncovered and exploited by an attacker
  • Impact - a measure of the technical and business impact of a successful attack

The values of each of these is then compared against a table to determine the "Overall Risk Severity", which will be one of Note, Low, Medium, High, or Critical, as per the following figure:

It should be up to each project to decide who handles calculating the severity, but in most cases it should likely be a lead (or group of leads) on the project who are well-versed on the OWASP risk rating methodology. The actual factor and severity scores which go into the calculation of the Overall Risk Severity should be documented on the Jira that is related to the security issue.

Developer Security Training and Assessment

After evaluating some of the available online training, it is the recommendation of this working group that we use the following training:

The total time of all the videos is around 2 hours and there are quizzes available for each topic. 

Proposed Developer Security Training process:

  1. When a new developer comes on the project, they have to sign their CLA as usual but also have to indicate in the Kuali Information System (KIS) that they have completed the Security training as well as taken the quizzes. That gets stored alongside of their CLA in KIS. The date at which they completed the training will be stored as well.
  2. Developers must have this completed and submitted this to KIS before they are given commit access (similar to the CLA process).
  3. We may periodically require a refresh for developers (which may only include new or updated topics) who are still active when new OWASP top 10 lists come out or new security training requirements arise.
  4. Only those with commit access to the projects will be required to complete this.
  5. Current developers with commit access will also be required to complete the training as well within an allotted time frame. The proposed time frame for this will be as follows:
    1. The new policy around developer security training will be announced via email to all developers and project managers on all Kuali projects.
    2. From the date this is announced, those who already have commit access will be given three months to complete the training and come into compliance with the new policy.
    3. Reminders will be sent at two months, one month, 2 weeks, 1 week, and 1 day. Starting at one month, a list will be provided to the project managers so they can see who has still not completed the required training.
    4. Once the allotted time has expired, a list of delinquent developers will be sent to the project managers. The project managers will then have one week to decide if anyone else from the list needs to be given more time before their commit access is revoked.
    5. At the end of the week, anyone not given amnesty by their project manager, will have their commit access revoked by the infrastructure team.
    6. Regaining this commit access will be easy, they just need to complete the training!

This will require the appropriate infrastructure to be put into KIS to track completion of the security training for each individual.

Screenshots of the planned UI in KIS to track this can be seen at the links below:

Tooling for Detection of Security Issues


Analysis still in progress

The group has narrowed the selection down to a handful of possible tools and will be attempting to do some hands-on experimentation with each of these tools. Based on the outcome of that effort, the group will make a recommendation of one or more tools. We will then need to determine available funding for the tools from there.

Some of the specific tools we are focusing on include:

  • IBM Security AppScan
  • HP WebInspect
  • Netsparker
  • Arachni (Open Source)
  • Syhunt Dynamic
    • Windows client tool; might be able to be run by CI tool, but not typical ootb configuration. Per Syhunt support: "We work with our customers to integrate the tools with their environments using the command line interface tools or Lua libraries. We never heard about the Jenkins platform before. Our dev team visited the Jenkins wiki today and I believe we can integrate the tools for you."
    • Was able to scan KFS and Rice sample app; only scanned 50% - some threads failed - may have been my laptop.
    • Took a long time run scan KFS (several hours)
    • Good scanning results; fairly easy to configure.
  • Qualys Guard
  • Burp
  • Acunetix
  • Whitehat Sentinel

See also: Review of Security Tools

Public-Facing Security Page

This group recommends that a public-facing page be created which includes the following information:

  1. How to report security vulnerabilities in a Kuali application.
  2. How the Kuali projects responds to such reports
  3. How the Kuali projects notify the community of security issues.
  4. The risk rating methodology that Kuali uses to rate security issues.
  5. The steps that Kuali has taken to try and produce more secure software (i.e. training, scanning tools, etc.)

We would recommend that this information be disseminated through a page off of the website which is highly visible and easily accessible. Ideally, typing would redirect to such a page. Ultimately, it may forward to a Confluence page, but it is important that it easy to locate this off the front page (or close to the front page) of the Kuali website.

The draft of this information replaced the Foundation Security page on 2/28, and the draft was subsequently removed:

Internal Documentation

Internal documentation needs to be developed which includes the following information:

  1. The process and procedure for responding to security alerts sent to
  2. How to apply the OWASP risk rating methodology when ranking security issues.
  3. The policy related to developers needing to have completed security training prior to being given commit access.
  4. How to use the security scanning tools (once they have been acquired and installed), including recommendations on how the tools should be integrated into the QA process for Kuali projects.


  • No labels