I reviewed runc 1.0.0~rc8+git20190923.3e425f80-0ubuntu1 as checked into focal.
This shouldn't be considered a full audit but rather a quick gauge of
maintainability.

runc, a lightweight universal container runtime, is a CLI tool for spawning and
running containers according to the Open Container Initiative (OCI) specification.

The runc .deb package contains lots of vendored code. This was already discussed
in the previous comments.

- CVE History:
  - CVE-2019-19921 - Race condition on volume mounting. Not fixed yet in upstream.
  - CVE-2019-16884 - Apparmor bypass. Currently fixed in eoan and focal.
  - CVE-2019-5736 - mishandling of file-descriptor, related to /proc/self/exe,
    may allow attacker to obtain host root access. Fixed in all active releases.
  - CVE-2016-9962 - privilege escalation allowed when opening a file-descriptor.
    Fixed in all active releases.
  - CVE-2016-3697 - privilege escalation because of improperly handling of
    usernames. Fixed in all active releases.
- Build-Depends
  - debhelper,
  - dh-golang,
  - go-md2man,
  - golang-any,
  - libapparmor-dev,
  - libseccomp-dev,
  - pkg-config,
  - protobuf-compiler
- No pre/post inst/rm scripts
- No init scripts
- No systemd units
- No dbus services
- No setuid binaries
- binaries in PATH
  - /usr/sbin/recvtty - recvtty is a reference implementation of a consumer of
    runC's --console-socket API.
  - /usr/sbin/runc - the command-line client for running containers.
- No sudo fragments
- No udev rules
- unit tests / autopkgtests
  - unit tests can be found under libcontainer/ and they test multiple
    functionalities of the code. They make use of Go's unit test framework.
    Unit tests are run during the package build.
  - Integrations tests provide end-to-end testing of runc, they can be found
    under tests/ and under libcontainer/.
- No cron jobs
- Build logs:
  - No build errors
  - No meaningful lintian failures

- Processes spawned
  - libcontainer/nsenter/nsexec.c:276:   execve(app, argv, envp);
    It try to call /proc/<pid>/uid_map or /pro/<pid>/gid_map
    Apparently the pid is retrieved from the environment variable
    _LIBCONTAINER_INITPIPE, "which was opened by the parent and kept open across
    the fork-exec of the `nsexec()` init"
  - libcontainer/nsenter/cloned_binary.c:512:  fexecve(execfd, argv, environ);
    Looks like it calls /proc/self/exe
- Memory management
  - A few .c file doing memory management, seems ok.
  - and a vendored secccomp code in golang doing a calloc.
- File IO
  - A few file IO in the C code of libcontainer, looks ok.
- Logging
  - make use of the errors package in some places.
  - but mostly uses logrus (vendored code)
- Environment variable usage
  - _LIBCONTAINER_INITPIPE
  - CLONED_BINARY_ENV
  - _LIBCONTAINER_STATEDIR
- Use of privileged functions
  - Seth took a look on those and the only relevant finding was reported here:
    https://github.com/opencontainers/runc/issues/2214
  - Nothing troublesome.
- Use of cryptography / random number sources:
  - Vendored godbus has a sha1 auth implementation. 
- Use of temp files
  - Some tests make use of /tmp and libcontainer uses /tmp when it wants to
    mount rootfs on tmpfs and also while cloning binaries.
- Use of networking
  - you can pass an AF_UNIX socket to runc so you can have a detached terminal.
  - nsexec also creates socket to make communication between parent and child
    process.
- No use of WebKit
- No use of PolicyKit

- Coverity issues:
 - 6 Issues listed by Coverity, all of them in vendored code.
 - 4 issues related to null pointer dereference
 - 1 issue of sha1 used in vendored godbus code
 - 1 issue related to unchecked return value
  

Security team ACK for promoting runc to main.