Follow-up to #39.
The dependency fix from #39 is done: the compiler now ships NuGet.Packaging 6.14.3 in dependencies.xml, so the NU1901 advisory no longer reaches user builds via the compiler host's DependencyRestore. That addressed the first ask of #39.
The second ask of #39 — enable proactive NuGet auditing in PostSharp''s own build pipeline so vulnerabilities surface in our CI rather than in customer builds — is still open.
Current state
NuGetAudit is on by default, so NU1901–NU1904 advisories appear as warnings in our build logs.- They are non-gating: nothing fails CI on a new advisory. The only
TreatWarningsAsErrors is for Release-config compile warnings, which does not reliably promote NU19xx restore warnings.
- Vulnerability auditing is therefore still a manual process (see
Documentation/Package Vulnerability Audit.md). A future vulnerable dependency could again reach customers before we notice.
Proposed work
- Promote restore vulnerability warnings to errors for the shipped + fetched dependency graphs, e.g.
<WarningsAsErrors>$(WarningsAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsAsErrors> (or MSBuildTreatWarningsAsErrors on restore) in a shared build props file.
- Exclude the internal-only
PostSharp.Build.Tasks, which legitimately carries advisories with no available fix (SharpCompress — no patched release ≤0.47.4; Microsoft.Build.Utilities.Core — host-provided MSBuild). These should not gate CI.
- Decide the severity threshold (e.g. gate on High/Critical = NU1903/NU1904, warn on Low/Moderate) so that unfixable Low/Moderate advisories do not permanently block the build.
- Optionally add a scheduled CI audit (the
.deps.proj / DependencyRestore graph is not covered by an ordinary project restore — see the audit doc) so newly published advisories against already-shipped versions are caught between releases.
Notes / open questions
- A hard gate on all NU19xx would currently break the build because of the internal-tooling advisories above; the exclusion + severity threshold are required, not optional.
- The DependencyRestore graph audit cannot rely on
dotnet list package --vulnerable (custom RestoreOutputPath); it needs a dotnet restore + NU19xx scan, as documented.
-- Claude for Gael
Follow-up to #39.
The dependency fix from #39 is done: the compiler now ships
NuGet.Packaging6.14.3 independencies.xml, so the NU1901 advisory no longer reaches user builds via the compiler host's DependencyRestore. That addressed the first ask of #39.The second ask of #39 — enable proactive NuGet auditing in PostSharp''s own build pipeline so vulnerabilities surface in our CI rather than in customer builds — is still open.
Current state
NuGetAuditis on by default, so NU1901–NU1904 advisories appear as warnings in our build logs.TreatWarningsAsErrorsis for Release-config compile warnings, which does not reliably promote NU19xx restore warnings.Documentation/Package Vulnerability Audit.md). A future vulnerable dependency could again reach customers before we notice.Proposed work
<WarningsAsErrors>$(WarningsAsErrors);NU1901;NU1902;NU1903;NU1904</WarningsAsErrors>(orMSBuildTreatWarningsAsErrorson restore) in a shared build props file.PostSharp.Build.Tasks, which legitimately carries advisories with no available fix (SharpCompress— no patched release ≤0.47.4;Microsoft.Build.Utilities.Core— host-provided MSBuild). These should not gate CI..deps.proj/ DependencyRestore graph is not covered by an ordinary project restore — see the audit doc) so newly published advisories against already-shipped versions are caught between releases.Notes / open questions
dotnet list package --vulnerable(customRestoreOutputPath); it needs adotnet restore+ NU19xx scan, as documented.-- Claude for Gael