Code & package load
How to manage code and packages for ingress to SEAD
Safely manage code and package requests
Safe management of user code and package requests is essential to maintaining a secure environment. The guidance below outlines how SEAD administrators manage these requests. SEAD users cannot load code or packages themselves, this responsibility sits with Data administrators under SEAD security protocols.
References to ‘code’ throughout this section include libraries, compiled code, packages and their dependencies. The ABS administers a Shared Library (L: Library drive) which holds approved code from STATA and SAS. The Shared Library is accessible to all users of the System. A Pod Library is also available to SEAD administrators, accessible only to the users of the SEADpod. R and Python code is made available through the Posit package manager available on researcher VM’s, upon request to ABS administrators.
Table 1 shows ABS endorsed repositories (CRAN, Pypi, ideas) that SEAD administrators can request packages. Their endorsement is based on the repository’s approach to security scanning, moderation, version control, vetting and are recognised as low risk for introducing malware to the system. Code from the ideas repository or simple self-produced code can be loaded by SEAD administrators to project gateway folders through Azure Storage Explorer. On request, ABS administrators will load code from CRAN and Pypi through the Posit package manager.
To maintain system security and integrity, SEAD administrators cannot load code from alternative repositories as outlined in Table 1, or directly from a researcher originating from an un-approved repository that has not been published or curated. These requests must be approved by the ABS via the Existing SEAD partner code and or software request. Ensure the request contains a valid business case and is consistent with the software request template below.
Table 1. Code Management Responsibilities
| Code/Package Request Origin | Can be accessed/loaded by: | |
|---|---|---|
| SEAD Administrators | ABS | |
| CRAN (R.) | Y | |
| Pypi | Y | |
| ideas (STATA) | Y | |
*Un-endorsed/alternative online repositories (i.e. Github and similar) AND Compiled code provided directly by researchers from an un-endorsed or unrecognised repository. | Y | |
| Basic/simple self-written produced code in text format | Y | |
| R & Python Package Manager (can be accessed by SEAD users, however, is administered by ABS)* | Y | |
| Software, drivers, plugins, executables and miscellaneous file types (macros, C++, .jar, binaries, compiled libraries etc) | Y | |
Software request template
To request additional software, please populate the Software Request Template on the SEAD 'Contact Us' webpage and email it to sead.support@abs.gov.au.
All requests are assessed by ABS on a case-by-case basis. Although SEAD operates in a closed, cloud-based environment, this process ensures a safe, efficient and repeatable approach to manage software loads, particularly where code may contain harmful malware or data.
In line with the Safe Settings principle of the Five Safes, SEAD administrators use the following mitigation measures when assessing code and package loads:
- Use recommended package repositories where possible (refer to the above table)
- Conduct appropriate vetting and escalation, with clear roles and checks (eg. ensuring no executables, appropriate dependencies)
- Rely on the SEADpod’s closed network system, along with Microsoft and organisational firewalls
- Apply compensating Safe People controls
Software must not to be supplied or attempted to be loaded (i.e. Winmerge, Winzip, Excel or any executable such as .exe) until a software assessment is completed and prioritised amongst existing SEAD development work with the ABS. Prioritisation is based on business justification and benefit to the broader user community and timing is dependent on available resources.
Users/clients may be advised that an assessment is required and will be informed if their requested software is approved for rollout.