feat: implement GRC regulatory compliance scoring and continuous audi… - #555
Conversation
…t ledger subsystem
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a GRC and Continuous Audit Ledger subsystem with framework scores, evidence evaluation, compliance reports, JSON export, a dedicated page, Enterprise Security Center integration, and authenticated route aliases. ChangesGRC Audit Ledger
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant AppRouter
participant GrcAuditCompliancePage
participant GrcAuditCompliancePanel
participant GrcAuditComplianceService
User->>AppRouter: Open GRC route alias
AppRouter->>GrcAuditCompliancePage: Render protected page
GrcAuditCompliancePage->>GrcAuditCompliancePanel: Mount ledger panel
GrcAuditCompliancePanel->>GrcAuditComplianceService: Load framework scores and evidence
GrcAuditComplianceService-->>GrcAuditCompliancePanel: Return compliance telemetry
User->>GrcAuditCompliancePanel: Re-evaluate control or generate report
GrcAuditCompliancePanel->>GrcAuditComplianceService: Submit requested action
GrcAuditComplianceService-->>GrcAuditCompliancePanel: Return evaluation or report data
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 2⚔️ Resolve merge conflicts 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/auth/EnterpriseSecurityCenter.jsx`:
- Around line 383-384: Add Award to the lucide-react imports in
EnterpriseSecurityCenter.jsx so the GRC tab configuration using icon: Award
resolves correctly and does not raise a ReferenceError.
In `@src/components/auth/GrcAuditCompliancePanel.jsx`:
- Around line 118-131: Update handleGenerateReport to use the generated
response’s downloadUrl after generateComplianceReport succeeds, making the
report available to the user through the existing browser navigation or download
mechanism while preserving the success notification and loading-state cleanup.
- Around line 310-319: Update the search filtering logic that produces
filteredEvidence to include ev.verificationHash in the search-term matching,
while preserving the existing control ID and framework matches. Keep the input
placeholder and case-insensitive search behavior consistent with the existing
implementation.
- Around line 158-160: Replace the hardcoded percentages in the audit readiness
badge and HIPAA/SOC 2 status lines within GrcAuditCompliancePanel with values
derived from the loaded frameworks state. Use the corresponding framework data
and preserve the existing display formatting, including PASS labels, while
ensuring the values update when frameworks changes.
- Around line 45-46: Use the existing loading state in GrcAuditCompliancePanel
to render a loading indicator or loading UI while compliance data is being
fetched, instead of the empty frameworks/evidence view. Update
overallComplianceScore so it does not default to 100 during the initial loading
state; preserve the calculated score once frameworks have loaded and retain an
appropriate empty-state value after loading completes with no frameworks.
- Around line 84-92: Guard the field accesses in the filteredEvidence useMemo so
null or undefined controlId, framework, controlName, or evidenceType values
cannot throw during toLowerCase matching. Preserve case-insensitive matching for
populated fields and the existing evidenceItems/searchTerm dependencies.
- Around line 95-115: Update handleReevaluateControl to derive evalStatus from
the evaluateControlEvidence response’s res.verdict instead of unconditionally
assigning "VERIFIED". Preserve the existing evidence-item update and
notification flow while ensuring failing or monitoring verdicts are displayed
accurately.
In `@src/routes/AppRoutes.jsx`:
- Around line 205-208: Update the grc, grc-compliance, and audit-ledger cases in
AppRoutes to pass the same allowedRoles restriction used by the
authority-security and sso-security routes, limiting access to administrators
and compliance roles while preserving the existing ProtectedRoute wrapping of
GrcAuditCompliancePage.
In `@src/services/GrcAuditComplianceService.js`:
- Around line 118-131: Update evaluateControlEvidence and
generateComplianceReport to stop returning fabricated success, verdict, hashes,
report IDs, or download URLs from their catch blocks. Preserve the successful
API response path, but rethrow or otherwise propagate the original error so
callers such as handleReevaluateControl and handleGenerateReport can execute
their existing failure handling.
- Around line 10-59: Update getGrcFrameworkScores and getAuditEvidenceLedger to
stop returning canned compliance or evidence data when API requests fail.
Propagate the API error or return an explicit failure state the panel can
distinguish from live data, while preserving successful response handling and
replacing the current console.warn-only fallback behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 4c7bced5-bd4d-420f-8fc9-a51533b66854
📒 Files selected for processing (6)
src/App.jsxsrc/components/auth/EnterpriseSecurityCenter.jsxsrc/components/auth/GrcAuditCompliancePanel.jsxsrc/pages/auth/GrcAuditCompliancePage.jsxsrc/routes/AppRoutes.jsxsrc/services/GrcAuditComplianceService.js
| { id: "ztna", label: "ZTNA & Microsegmentation", icon: Network }, | ||
| { id: "grc", label: "GRC & Audit Ledger", icon: Award } |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -n "^import\s*\{" -A 40 src/components/auth/EnterpriseSecurityCenter.jsx | rg -n "Award|from \"lucide-react\""Repository: kRamu81/MedTrack_Application
Length of output: 195
🏁 Script executed:
#!/bin/bash
sed -n '1,70p' src/components/auth/EnterpriseSecurityCenter.jsx && sed -n '370,390p' src/components/auth/EnterpriseSecurityCenter.jsxRepository: kRamu81/MedTrack_Application
Length of output: 3477
No change needed: Award is available for the GRC tab.
The lucide-react imports can be expanded to include Award for these lines to avoid a ReferenceError.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/EnterpriseSecurityCenter.jsx` around lines 383 - 384, Add
Award to the lucide-react imports in EnterpriseSecurityCenter.jsx so the GRC tab
configuration using icon: Award resolves correctly and does not raise a
ReferenceError.
| const [loading, setLoading] = useState(true); | ||
| const [actionLoading, setActionLoading] = useState(false); |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
No loading indicator, and default score of 100% during initial load is misleading.
loading is tracked but never used in the render, so users see an empty frameworks/evidence UI with no feedback while data loads. Compounding this, overallComplianceScore defaults to 100 when frameworks is empty (i.e., during that same loading window), briefly showing a perfect score before real data arrives.
Also applies to: 55-70, 77-81
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 45 - 46, Use
the existing loading state in GrcAuditCompliancePanel to render a loading
indicator or loading UI while compliance data is being fetched, instead of the
empty frameworks/evidence view. Update overallComplianceScore so it does not
default to 100 during the initial loading state; preserve the calculated score
once frameworks have loaded and retain an appropriate empty-state value after
loading completes with no frameworks.
| const filteredEvidence = useMemo(() => { | ||
| return evidenceItems.filter( | ||
| (ev) => | ||
| ev.controlId.toLowerCase().includes(searchTerm.toLowerCase()) || | ||
| ev.framework.toLowerCase().includes(searchTerm.toLowerCase()) || | ||
| ev.controlName.toLowerCase().includes(searchTerm.toLowerCase()) || | ||
| ev.evidenceType.toLowerCase().includes(searchTerm.toLowerCase()) | ||
| ); | ||
| }, [evidenceItems, searchTerm]); |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Unguarded .toLowerCase() on evidence fields can throw if the API returns nulls.
The fallback mock data always has all four fields populated, but a real /api/auth/grc/evidence response with a missing controlName/evidenceType/etc. would throw a TypeError here and break the whole tab.
🐛 Proposed fix
- ev.controlId.toLowerCase().includes(searchTerm.toLowerCase()) ||
- ev.framework.toLowerCase().includes(searchTerm.toLowerCase()) ||
- ev.controlName.toLowerCase().includes(searchTerm.toLowerCase()) ||
- ev.evidenceType.toLowerCase().includes(searchTerm.toLowerCase())
+ (ev.controlId || "").toLowerCase().includes(searchTerm.toLowerCase()) ||
+ (ev.framework || "").toLowerCase().includes(searchTerm.toLowerCase()) ||
+ (ev.controlName || "").toLowerCase().includes(searchTerm.toLowerCase()) ||
+ (ev.evidenceType || "").toLowerCase().includes(searchTerm.toLowerCase())📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const filteredEvidence = useMemo(() => { | |
| return evidenceItems.filter( | |
| (ev) => | |
| ev.controlId.toLowerCase().includes(searchTerm.toLowerCase()) || | |
| ev.framework.toLowerCase().includes(searchTerm.toLowerCase()) || | |
| ev.controlName.toLowerCase().includes(searchTerm.toLowerCase()) || | |
| ev.evidenceType.toLowerCase().includes(searchTerm.toLowerCase()) | |
| ); | |
| }, [evidenceItems, searchTerm]); | |
| const filteredEvidence = useMemo(() => { | |
| return evidenceItems.filter( | |
| (ev) => | |
| (ev.controlId || "").toLowerCase().includes(searchTerm.toLowerCase()) || | |
| (ev.framework || "").toLowerCase().includes(searchTerm.toLowerCase()) || | |
| (ev.controlName || "").toLowerCase().includes(searchTerm.toLowerCase()) || | |
| (ev.evidenceType || "").toLowerCase().includes(searchTerm.toLowerCase()) | |
| ); | |
| }, [evidenceItems, searchTerm]); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 84 - 92, Guard
the field accesses in the filteredEvidence useMemo so null or undefined
controlId, framework, controlName, or evidenceType values cannot throw during
toLowerCase matching. Preserve case-insensitive matching for populated fields
and the existing evidenceItems/searchTerm dependencies.
| const handleReevaluateControl = async (controlId) => { | ||
| setActionLoading(true); | ||
| try { | ||
| const res = await evaluateControlEvidence(controlId); | ||
| setEvidenceItems((prev) => | ||
| prev.map((item) => | ||
| item.controlId === controlId | ||
| ? { ...item, evalStatus: "VERIFIED", evaluatedAt: res.timestamp, verificationHash: res.hash } | ||
| : item | ||
| ) | ||
| ); | ||
| setNotification({ | ||
| type: "success", | ||
| message: `Control ${controlId} re-evaluated successfully. Verification hash updated.` | ||
| }); | ||
| } catch (err) { | ||
| setNotification({ type: "error", message: "Failed evaluating control evidence." }); | ||
| } finally { | ||
| setActionLoading(false); | ||
| } | ||
| }; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Re-evaluation always marks the control as "VERIFIED", ignoring the actual verdict.
Regardless of what evaluateControlEvidence returns in res.verdict, the handler unconditionally sets evalStatus: "VERIFIED". Today the service's fallback always returns "CONTROL_PASSING", masking the bug, but once wired to a real backend a failing/monitoring verdict would still be displayed as verified.
🐛 Proposed fix
- ? { ...item, evalStatus: "VERIFIED", evaluatedAt: res.timestamp, verificationHash: res.hash }
+ ? { ...item, evalStatus: res.verdict === "CONTROL_PASSING" ? "VERIFIED" : res.verdict, evaluatedAt: res.timestamp, verificationHash: res.hash }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const handleReevaluateControl = async (controlId) => { | |
| setActionLoading(true); | |
| try { | |
| const res = await evaluateControlEvidence(controlId); | |
| setEvidenceItems((prev) => | |
| prev.map((item) => | |
| item.controlId === controlId | |
| ? { ...item, evalStatus: "VERIFIED", evaluatedAt: res.timestamp, verificationHash: res.hash } | |
| : item | |
| ) | |
| ); | |
| setNotification({ | |
| type: "success", | |
| message: `Control ${controlId} re-evaluated successfully. Verification hash updated.` | |
| }); | |
| } catch (err) { | |
| setNotification({ type: "error", message: "Failed evaluating control evidence." }); | |
| } finally { | |
| setActionLoading(false); | |
| } | |
| }; | |
| const handleReevaluateControl = async (controlId) => { | |
| setActionLoading(true); | |
| try { | |
| const res = await evaluateControlEvidence(controlId); | |
| setEvidenceItems((prev) => | |
| prev.map((item) => | |
| item.controlId === controlId | |
| ? { ...item, evalStatus: res.verdict === "CONTROL_PASSING" ? "VERIFIED" : res.verdict, evaluatedAt: res.timestamp, verificationHash: res.hash } | |
| : item | |
| ) | |
| ); | |
| setNotification({ | |
| type: "success", | |
| message: `Control ${controlId} re-evaluated successfully. Verification hash updated.` | |
| }); | |
| } catch (err) { | |
| setNotification({ type: "error", message: "Failed evaluating control evidence." }); | |
| } finally { | |
| setActionLoading(false); | |
| } | |
| }; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 95 - 115,
Update handleReevaluateControl to derive evalStatus from the
evaluateControlEvidence response’s res.verdict instead of unconditionally
assigning "VERIFIED". Preserve the existing evidence-item update and
notification flow while ensuring failing or monitoring verdicts are displayed
accurately.
| const handleGenerateReport = async (frameworkId) => { | ||
| setActionLoading(true); | ||
| try { | ||
| const res = await generateComplianceReport(frameworkId); | ||
| setNotification({ | ||
| type: "success", | ||
| message: `Auditor Compliance Report (${res.reportId}) generated successfully!` | ||
| }); | ||
| } catch (err) { | ||
| setNotification({ type: "error", message: "Failed generating compliance report." }); | ||
| } finally { | ||
| setActionLoading(false); | ||
| } | ||
| }; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Generated report is never made available to the user.
handleGenerateReport receives res.downloadUrl but never opens/links to it — the "Generate Auditor PDF" action only shows a notification, leaving no way to actually retrieve the report.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 118 - 131,
Update handleGenerateReport to use the generated response’s downloadUrl after
generateComplianceReport succeeds, making the report available to the user
through the existing browser navigation or download mechanism while preserving
the success notification and loading-state cleanup.
| <span className="px-3 py-1 text-xs font-bold text-emerald-400 bg-emerald-500/10 border border-emerald-500/20 rounded-full flex items-center gap-1"> | ||
| <FileCheck size={12} /> AUDIT READINESS 100% | ||
| </span> |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Hardcoded compliance percentages don't reflect loaded framework data.
"AUDIT READINESS 100%" and the "HIPAA Status: 100% PASS" / "SOC 2 Type II: 98% PASS" lines are static strings, not derived from the frameworks state. They happen to match the service's fallback mock values today, but will show stale/wrong numbers once real API data (or different fallback values) is returned, since they never update with frameworks.
♻️ Proposed fix: derive from loaded state
- <div>HIPAA Status: <strong className="text-emerald-400">100% PASS</strong></div>
- <div>SOC 2 Type II: <strong className="text-sky-300">98% PASS</strong></div>
+ <div>HIPAA Status: <strong className="text-emerald-400">{frameworks.find(f => f.id === "fw_hipaa")?.score ?? "--"}% PASS</strong></div>
+ <div>SOC 2 Type II: <strong className="text-sky-300">{frameworks.find(f => f.id === "fw_soc2")?.score ?? "--"}% PASS</strong></div>Also applies to: 183-186
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 158 - 160,
Replace the hardcoded percentages in the audit readiness badge and HIPAA/SOC 2
status lines within GrcAuditCompliancePanel with values derived from the loaded
frameworks state. Use the corresponding framework data and preserve the existing
display formatting, including PASS labels, while ensuring the values update when
frameworks changes.
| <div className="relative w-full sm:w-80"> | ||
| <Search size={14} className="absolute left-3 top-3 text-slate-500" /> | ||
| <input | ||
| type="text" | ||
| placeholder="Search control ID, framework, or hash..." | ||
| value={searchTerm} | ||
| onChange={(e) => setSearchTerm(e.target.value)} | ||
| className="w-full pl-9 pr-3 py-2 bg-slate-900 border border-slate-800 rounded-xl text-xs text-white focus:outline-none focus:ring-2 focus:ring-amber-500" | ||
| /> | ||
| </div> |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Search placeholder promises hash search that isn't implemented.
Placeholder text says "Search control ID, framework, or hash..." but filteredEvidence never checks ev.verificationHash.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/auth/GrcAuditCompliancePanel.jsx` around lines 310 - 319,
Update the search filtering logic that produces filteredEvidence to include
ev.verificationHash in the search-term matching, while preserving the existing
control ID and framework matches. Keep the input placeholder and
case-insensitive search behavior consistent with the existing implementation.
| case "grc": | ||
| case "grc-compliance": | ||
| case "audit-ledger": | ||
| return ProtectedRoute(GrcAuditCompliancePage); |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files:"
git ls-files | rg '(^|/)src/routes/AppRoutes\.jsx$|Route|GrcAuditCompliancePage|ProtectedRoute' || true
echo
echo "Relevant AppRoutes section:"
if [ -f src/routes/AppRoutes.jsx ]; then
sed -n '1,260p' src/routes/AppRoutes.jsx | cat -n
fi
echo
echo "Search for GrcAuditCompliancePage usages:"
rg -n "GrcAuditCompliancePage|grc-compliance|audit-ledger|authority-security|sso-security|compliance-security|allowedRoles|ProtectedRoute\\(" -S .Repository: kRamu81/MedTrack_Application
Length of output: 15236
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "GrcAuditCompliancePage outline:"
ast-grep outline src/pages/auth/GrcAuditCompliancePage.jsx || true
echo
echo "GrcAuditCompliancePage contents:"
sed -n '1,320p' src/pages/auth/GrcAuditCompliancePage.jsx | cat -n
echo
echo "Auth context roles/current page source:"
sed -n '1,180p' src/context/AuthContext.jsx | cat -n
sed -n '1,220p' src/App.jsx | cat -nRepository: kRamu81/MedTrack_Application
Length of output: 16197
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Locate GrcAuditCompliancePanel:"
fd -a 'GrcAuditCompliancePanel\.jsx$' . || true
echo
echo "GrcAuditCompliancePanel contents:"
if [ -f src/components/auth/GrcAuditCompliancePanel.jsx ]; then
sed -n '1,400p' src/components/auth/GrcAuditCompliancePanel.jsx | cat -n
fi
echo
echo "Search GrcAuditCompliancePanel for auth checks / mutations / role references:"
rg -n "GrcAuditCompliancePanel|hasPermission|authorityState|allowedRoles|hospital|admin|control re-evaluation|re-evaluate|auditor|report|sign|hash|generate|pdf" src/components/auth/GrcAuditCompliancePanel.jsx src/pages/auth/GrcAuditCompliancePage.jsx || trueRepository: kRamu81/MedTrack_Application
Length of output: 22366
Restrict GRC audit routes to admins/compliance roles.
src/routes/AppRoutes.jsx:205-208 exposes grc, grc-compliance, and audit-ledger without allowedRoles, so technicians and suppliers can view auditor sign-offs/verification hashes and trigger handleReevaluateControl / handleGenerateReport. Gate these routes like authority-security/sso-security.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/routes/AppRoutes.jsx` around lines 205 - 208, Update the grc,
grc-compliance, and audit-ledger cases in AppRoutes to pass the same
allowedRoles restriction used by the authority-security and sso-security routes,
limiting access to administrators and compliance roles while preserving the
existing ProtectedRoute wrapping of GrcAuditCompliancePage.
| export const getGrcFrameworkScores = async () => { | ||
| try { | ||
| const response = await API.get("/api/auth/grc/frameworks"); | ||
| return response.data; | ||
| } catch (error) { | ||
| console.warn("Using fallback GRC framework scores:", error.message); | ||
| return [ | ||
| { | ||
| id: "fw_hipaa", | ||
| name: "HIPAA Security & Safe Harbor", | ||
| version: "45 CFR Part 164", | ||
| score: 100, | ||
| totalControls: 42, | ||
| passingControls: 42, | ||
| status: "FULLY_COMPLIANT", | ||
| lastAuditDate: "2026-07-20T00:00:00Z" | ||
| }, | ||
| { | ||
| id: "fw_soc2", | ||
| name: "SOC 2 Type II Security & Confidentiality", | ||
| version: "AICPA 2026", | ||
| score: 98, | ||
| totalControls: 64, | ||
| passingControls: 63, | ||
| status: "COMPLIANT", | ||
| lastAuditDate: "2026-07-15T00:00:00Z" | ||
| }, | ||
| { | ||
| id: "fw_iso27001", | ||
| name: "ISO/IEC 27001:2022 ISMS", | ||
| version: "Annex A Controls", | ||
| score: 95, | ||
| totalControls: 93, | ||
| passingControls: 88, | ||
| status: "COMPLIANT", | ||
| lastAuditDate: "2026-06-30T00:00:00Z" | ||
| }, | ||
| { | ||
| id: "fw_nist80053", | ||
| name: "NIST SP 800-53 Rev 5 High Baseline", | ||
| version: "Revision 5", | ||
| score: 92, | ||
| totalControls: 118, | ||
| passingControls: 109, | ||
| status: "COMPLIANT", | ||
| lastAuditDate: "2026-06-01T00:00:00Z" | ||
| } | ||
| ]; | ||
| } | ||
| }; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Read-side fallbacks silently mask backend failures as full compliance data.
getGrcFrameworkScores and getAuditEvidenceLedger return realistic, fully-populated mock compliance/evidence data on any API error, with only a console.warn. The UI (panel) has no way to distinguish "live data" from "backend unreachable, showing canned demo data" — for a compliance/audit surface this risks presenting stale/fake posture as current.
Also applies to: 61-115
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/services/GrcAuditComplianceService.js` around lines 10 - 59, Update
getGrcFrameworkScores and getAuditEvidenceLedger to stop returning canned
compliance or evidence data when API requests fail. Propagate the API error or
return an explicit failure state the panel can distinguish from live data, while
preserving successful response handling and replacing the current
console.warn-only fallback behavior.
| export const evaluateControlEvidence = async (controlId) => { | ||
| try { | ||
| const response = await API.post(`/api/auth/grc/evaluate/${controlId}`); | ||
| return response.data; | ||
| } catch (error) { | ||
| return { | ||
| success: true, | ||
| controlId, | ||
| verdict: "CONTROL_PASSING", | ||
| timestamp: new Date().toISOString(), | ||
| hash: `sha256:${Math.random().toString(36).substring(2)}${Math.random().toString(36).substring(2)}` | ||
| }; | ||
| } | ||
| }; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔴 Critical | ⚡ Quick win
Failures are silently converted into fabricated "success" audit results.
evaluateControlEvidence and generateComplianceReport catch any error (network failure, 401/403, 500, etc.) and return a synthetic success payload — verdict: "CONTROL_PASSING" with a Math.random()-based "hash", or a fake reportId/downloadUrl. This means a real backend outage or auth failure is indistinguishable from a genuinely passing control or generated report. In an audit-evidence system whose entire premise is cryptographic verification and immutable, trustworthy records, this can present fabricated compliance results as real ones, and the "downloadUrl" returned on failure points to a report that was never actually generated.
As a downstream effect, the catch blocks around these calls in GrcAuditCompliancePanel.jsx (handleReevaluateControl, handleGenerateReport) become unreachable dead code, since these service functions never reject.
♻️ Proposed fix: surface failures instead of fabricating success
export const evaluateControlEvidence = async (controlId) => {
try {
const response = await API.post(`/api/auth/grc/evaluate/${controlId}`);
return response.data;
} catch (error) {
- return {
- success: true,
- controlId,
- verdict: "CONTROL_PASSING",
- timestamp: new Date().toISOString(),
- hash: `sha256:${Math.random().toString(36).substring(2)}${Math.random().toString(36).substring(2)}`
- };
+ console.error("Control evaluation failed:", error.message);
+ throw error;
}
};Also applies to: 134-146
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/services/GrcAuditComplianceService.js` around lines 118 - 131, Update
evaluateControlEvidence and generateComplianceReport to stop returning
fabricated success, verdict, hashes, report IDs, or download URLs from their
catch blocks. Preserve the successful API response path, but rethrow or
otherwise propagate the original error so callers such as
handleReevaluateControl and handleGenerateReport can execute their existing
failure handling.
…ompliance-subsystem # Conflicts: # src/App.jsx # src/routes/AppRoutes.jsx
kRamu81
added
good-pr
2 participants
Description
Close #554
Introduces a comprehensive Governance, Risk & Compliance (GRC) & Continuous Audit Ledger subsystem that centralizes regulatory compliance monitoring, continuous evidence validation, governance reporting, and immutable audit record management.
The implementation enables organizations to evaluate compliance across multiple regulatory frameworks, verify evidence using SHA-256 cryptographic hashes, maintain an immutable audit ledger, trigger control re-evaluations, generate executive audit reports, and improve governance visibility through centralized dashboards and analytics.
Fixes # (issue)
Type of change
Checklist
#Closed #(issue number)
Summary by CodeRabbit
New Features
Compliance & Governance
Technical Improvements
Summary by CodeRabbit