Skip to content

Code privacy

Public repositories have secrets scanning enabled to alert organization owners when secrets are committed.

In order to protect the Students, Faculty, and Staff of the University of Minnesota, extra precaution should be taken not to compromise the privacy of University data. Where possible, find ways to not hard code any data that could be considered private, or which will enable attackers to access private data if vulnerabilities exist.

See also: The Office of General Counsel's page on Public and Private Information for general considerations about University data visibility.

Considerations for code privacy#

In general, most code does not need to be public, especially code used for business processes or more internal configuration. If collaboration is desired, consider your code and whether it contains information that either directly compromises private information or gives potential attackers the blueprints for how to access this information.

  • Is there less obvious data hard coded somewhere and can it be relativized?
    • firewall configuration (including VPN)
    • internal host names
    • admin account references or secrets
  • Is there code (like web service configs) that can be vulnerable to cross site scripting (XSS) or other intrusions, and have you tested or scanned it to prevent this?
  • Is the system the code is connected to one that contains federally protection information (e.g. FERPA, HIPAA, PCI, etc)?
    • there might be ways to segment the code to protect that data

Consider open source#

Is this code written for people outside of the University?

  • If the code is being used for specific things internally, consider cloning it to a sanitized version that can be made public instead

For guidance on licensing, the Office of Tech Commercialization (umotc@umn.edu) can assist a team with selecting an appropriate license for the goals of the application.

Other Guidelines and Tips for Security#

  1. Protect your default/main branch. Especially when you have Actions attached to the branch.
  2. Rotate SSH Keys and Tokens often.
  3. Secret Scanning is turned on for all public repositories, but not internal and private (it costs money; DevEx looking into it).
  4. Sign commits to verify it's you. About Commit Verification
  5. Setup Static Code Analyzers, as a precommit hook and/or in your Actions automations.

Additional resources to check out#

When in doubt, reach out to UIS! security@umn.edu