You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DefectDojo hook specifies inconsistent timezones in test description #750
The DefectDojo hook automatically creates a product, engagement and test when uploading data, and, among other things, sets the description of the test to include the time of the scan. However, it seems different timezones for the start and end time it reports, because this is the result for a scan started at 9:49 a.m. local time / 7:49 a.m. UTC that lasts around a minute:
The error is likely in the hook, because 9:49 does not appear anywhere in the secureCodeBox scan results:
I've taken another look at this. It seems like this was an artifact of manually testing the hook instead of having it run in the cluster.
The discrepancy results from the DescriptionGenerator.java class: the start time is taken from the finding, but the end time is taken from LocalDateTime.now(clock), with Clock clock = Clock.systemDefaultZone();. It seems like the k8s system is using UTC / Zulu time by default, while locally executing it outside of the cluster used my laptops timezone (which was UTC+2 at that time due to DST).
I guess this means that no changes are necessary, since the expected method is to run the hook inside the cluster anyway. Otherwise, we could always explicitly cast everything to UTC, but I don't think this is necessary here.
Activity
malexmave commentedon Nov 3, 2021
I've taken another look at this. It seems like this was an artifact of manually testing the hook instead of having it run in the cluster.
The discrepancy results from the DescriptionGenerator.java class: the start time is taken from the finding, but the end time is taken from
LocalDateTime.now(clock), withClock clock = Clock.systemDefaultZone();. It seems like the k8s system is using UTC / Zulu time by default, while locally executing it outside of the cluster used my laptops timezone (which was UTC+2 at that time due to DST).I guess this means that no changes are necessary, since the expected method is to run the hook inside the cluster anyway. Otherwise, we could always explicitly cast everything to UTC, but I don't think this is necessary here.