[Summary]
MIR Team ack to promote liboepnscap8 and the source (will auto-promote libopensacp-dev).
There are a few suggestions to improve the package (see below), if (ever) more of the package shall be promoted those are s/optional/required/ then.
This does need a security review, so I'll assign ubuntu-security

TODO:
- Please work on converting python-openscap to python3 (not gating the promotion).
- given the low quality (many open issues) this might cause quite some work, so be suer that you want to own this in Ubuntu
- please consider adding symbols tracking
- how about bumping at least groovy to the latest much newer version 1.3.3?
- new -dbg style?
- adopt debhelper >9

There are no massive differences between the releases. So the request to promote in older releases should be ok if the release and SRU team agrees.
I'm sure the archive admins will know if that is allowed.
Bionic: 1.2.15-1ubuntu0.1
Focal: 1.2.16-2ubuntu3
-dev: 1.2.16-2ubuntu5

[Duplication]
There is no other package in main providing the same functionality for SCAP definitions.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
  The one that is packages has no odd dependencies, so no exclusion needed

Problems:
- other Dependencies to MIR due to this
  - most dependencies are in main already, except one concerning bit
    python-openscap is pure python2
=> That means:
  - you can't promote that binary in >=Focal, do you need it?
    You wrote that you need "libopenscap8" so that might be ok for you
  - Never the less to be safer you should consider working on getting
    it a python3-openscap and drop python-openscap

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
  There is src:openscap-daemon, but no one depends on it
- does not use webkit1,2
- does not use lib*v8 directly 
- does not open a port
- does not process arbitrary web content
  TBH that depends on the user of the lib
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
 - does not deal with system authentication (eg, pam), etc)

Problems:
- does parse data formats

A quick security review on the data parsing bits of the lib would be good, just so it isn't obviously running into classic parsing/buffer issues and such.
Given that it is from a security background one would hope it is fine, but a quick check can't hurt.

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber (ubuntu-security)
- no translation present, but none needed for this case (user visible)?
- Python package that is using dh_python
- Not a Go package that uses dh-golang

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
- new python2 dependency

This matches your report of an overall low-medium quality.
You will have to own it once promoted and have to be clear to work on all these issues when affecting Ubuntu users.


[Packaging red flags]
OK:
- d/watch is present and looks ok
- Upstream update history is ok, but slow
- Debian/Ubuntu update history is ok
- promoting this does not seem to cause issues for MOTUs that so far (per CL history)
  maintained the package
- no massive Lintian warnings
- d/rules is sort of ok (many overrides)
- not using Built-Using
- Does not have Built-Using

Problems:
- Ubuntu does carry a delta
  Gladly it isn't too complex.
  I'd recommend getting that to Debian, nothing seems Ubuntu specific.
  But OTOH you already said Debian isn't very active
- symbols tracking is in place
  Would you mind adding that for some quality (at least going forward)?
- the current release is packaged - 1.2.16 vs 1.3.3
  Any reason not to change, could that be tried?
- old style -dbg package
- dh9 is deprecated

[Upstream red flags]
OK:
- no Errors/warnings during the build
  A long list of silly lack of "defined" thrown as warnings
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
  - except the known case that you are aware
  - upstream has some bad reports
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks