Update CI workflow and contribution guidelines
This commit is contained in:
164
CONTRIBUTING.md
164
CONTRIBUTING.md
@@ -1,148 +1,40 @@
|
|||||||
# Contributing to Ghost
|
# Contributing to Ghost
|
||||||
|
|
||||||
## Development Setup
|
Thank you for your interest in contributing to Ghost!
|
||||||
|
|
||||||
### Prerequisites
|
## Getting Started
|
||||||
- Rust 1.70+ (stable)
|
|
||||||
- Windows SDK for Windows development
|
|
||||||
- Visual Studio Build Tools
|
|
||||||
|
|
||||||
### Building
|
1. Fork the repository
|
||||||
```bash
|
2. Clone your fork
|
||||||
git clone https://github.com/pandaadir05/ghost.git
|
3. Create a branch: `git checkout -b feature/your-feature`
|
||||||
cd ghost
|
4. Make changes and test: `cargo test --all`
|
||||||
cargo build
|
5. Format code: `cargo fmt --all`
|
||||||
```
|
6. Check lints: `cargo clippy --all`
|
||||||
|
7. Commit: `git commit -m "feat: description"`
|
||||||
### Testing
|
8. Push and open a Pull Request
|
||||||
```bash
|
|
||||||
cargo test
|
|
||||||
cargo run --bin ghost-cli
|
|
||||||
```
|
|
||||||
|
|
||||||
## Code Style
|
## Code Style
|
||||||
|
|
||||||
### Rust Guidelines
|
- Follow Rust conventions
|
||||||
- Use `rustfmt` with default settings
|
- Use rustfmt and clippy
|
||||||
- All public APIs must have documentation
|
- Write clear, documented code
|
||||||
- Follow Rust naming conventions
|
- Add tests for new features
|
||||||
- Prefer explicit error handling over `.unwrap()`
|
|
||||||
|
|
||||||
### Commit Messages
|
## Commit Messages
|
||||||
Follow conventional commits:
|
|
||||||
- `feat: add new detection technique`
|
|
||||||
- `fix: resolve false positive in memory scanning`
|
|
||||||
- `perf: optimize syscall hook performance`
|
|
||||||
- `docs: update detection coverage matrix`
|
|
||||||
- `refactor: extract platform-specific code`
|
|
||||||
|
|
||||||
## Detection Development
|
Use conventional commits:
|
||||||
|
- `feat:` New feature
|
||||||
|
- `fix:` Bug fix
|
||||||
|
- `docs:` Documentation
|
||||||
|
- `refactor:` Code refactoring
|
||||||
|
- `test:` Tests
|
||||||
|
|
||||||
### Adding New Techniques
|
## Areas for Contribution
|
||||||
1. Research the injection method thoroughly
|
|
||||||
2. Implement detection in `ghost-core/src/detection.rs`
|
|
||||||
3. Add tests in `tests/detection/`
|
|
||||||
4. Update documentation in `docs/DETECTION_METHODS.md`
|
|
||||||
5. Add benchmark if performance critical
|
|
||||||
|
|
||||||
### Platform Support
|
- macOS support
|
||||||
- Windows: Primary platform, full feature support
|
- Threat intelligence feeds
|
||||||
- Linux: eBPF-based detection (in progress)
|
- eBPF implementation
|
||||||
- macOS: Endpoint Security framework (planned)
|
- Test coverage
|
||||||
|
- Documentation
|
||||||
|
|
||||||
## Testing
|
Thank you for contributing!
|
||||||
|
|
||||||
### Unit Tests
|
|
||||||
Focus on:
|
|
||||||
- Detection accuracy (no false positives)
|
|
||||||
- Edge case handling
|
|
||||||
- Memory safety
|
|
||||||
- Performance regressions
|
|
||||||
|
|
||||||
### Integration Tests
|
|
||||||
- Real injection techniques (in controlled environment)
|
|
||||||
- Cross-platform compatibility
|
|
||||||
- Performance benchmarks
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
|
|
||||||
### Code Comments
|
|
||||||
```rust
|
|
||||||
/// Detects process hollowing by analyzing memory layout gaps.
|
|
||||||
///
|
|
||||||
/// This technique monitors for unusual memory allocation patterns
|
|
||||||
/// where the original executable sections are unmapped and replaced
|
|
||||||
/// with malicious code while preserving the process structure.
|
|
||||||
///
|
|
||||||
/// # Arguments
|
|
||||||
/// * `regions` - Memory regions from VirtualQueryEx
|
|
||||||
///
|
|
||||||
/// # Returns
|
|
||||||
/// Confidence score 0.0-1.0 indicating hollowing likelihood
|
|
||||||
```
|
|
||||||
|
|
||||||
### Security Considerations
|
|
||||||
- All detection methods must be documented
|
|
||||||
- Include MITRE ATT&CK technique mappings
|
|
||||||
- Reference academic papers where applicable
|
|
||||||
- Provide reproducible test cases
|
|
||||||
|
|
||||||
## Review Process
|
|
||||||
|
|
||||||
### Pull Requests
|
|
||||||
1. All tests must pass
|
|
||||||
2. Code coverage >85%
|
|
||||||
3. Documentation updated
|
|
||||||
4. Performance impact assessed
|
|
||||||
5. Security review for new detection logic
|
|
||||||
|
|
||||||
### Performance Requirements
|
|
||||||
- Memory enumeration: <100ms per process
|
|
||||||
- Thread analysis: <50ms per process
|
|
||||||
- Detection engine: <10ms per analysis
|
|
||||||
- Total scan time: <5s for 200 processes
|
|
||||||
|
|
||||||
## Architecture
|
|
||||||
|
|
||||||
### Core Principles
|
|
||||||
- Zero false positives
|
|
||||||
- Minimal performance impact
|
|
||||||
- Cross-platform compatibility
|
|
||||||
- Educational value
|
|
||||||
|
|
||||||
### Module Structure
|
|
||||||
```
|
|
||||||
ghost-core/
|
|
||||||
├── detection.rs # Core detection algorithms
|
|
||||||
├── memory.rs # Memory enumeration
|
|
||||||
├── process.rs # Process management
|
|
||||||
├── thread.rs # Thread analysis
|
|
||||||
└── platform/ # OS-specific implementations
|
|
||||||
├── windows/
|
|
||||||
├── linux/
|
|
||||||
└── macos/
|
|
||||||
```
|
|
||||||
|
|
||||||
## Security Research
|
|
||||||
|
|
||||||
### Responsible Disclosure
|
|
||||||
- Test only on systems you own
|
|
||||||
- Report bypasses through security contacts
|
|
||||||
- Include proof-of-concept code
|
|
||||||
- Coordinate with maintainers
|
|
||||||
|
|
||||||
### Research Areas
|
|
||||||
- Novel injection techniques
|
|
||||||
- Evasion methods
|
|
||||||
- Performance optimizations
|
|
||||||
- Anti-analysis detection
|
|
||||||
|
|
||||||
## Questions?
|
|
||||||
|
|
||||||
Open an issue for:
|
|
||||||
- Feature requests
|
|
||||||
- Bug reports
|
|
||||||
- Documentation improvements
|
|
||||||
- Design discussions
|
|
||||||
|
|
||||||
For security issues, email: .
|
|
||||||
|
|||||||
96
SECURITY.md
96
SECURITY.md
@@ -6,84 +6,40 @@
|
|||||||
| ------- | ------------------ |
|
| ------- | ------------------ |
|
||||||
| 0.1.x | :white_check_mark: |
|
| 0.1.x | :white_check_mark: |
|
||||||
|
|
||||||
## Reporting a Vulnerability
|
## Authorized Use
|
||||||
|
|
||||||
We take security vulnerabilities seriously. If you discover a security issue in Ghost, please follow these steps:
|
Ghost is designed for:
|
||||||
|
- Authorized security testing
|
||||||
|
- Defensive security operations
|
||||||
|
- CTF challenges
|
||||||
|
- Security research and education
|
||||||
|
|
||||||
### For Security Researchers
|
## Reporting Vulnerabilities
|
||||||
|
|
||||||
1. **DO NOT** create a public GitHub issue for security vulnerabilities
|
**Do NOT** open public issues for security vulnerabilities.
|
||||||
2. Include detailed information about the vulnerability:
|
|
||||||
- Steps to reproduce
|
Contact: Create a private security advisory on GitHub
|
||||||
- Potential impact
|
|
||||||
- Suggested fix (if any)
|
|
||||||
- Your contact information
|
|
||||||
|
|
||||||
### Response Timeline
|
### Response Timeline
|
||||||
|
|
||||||
- **Initial Response**: Within 48 hours
|
- Acknowledgment: 48 hours
|
||||||
- **Assessment**: Within 7 days
|
- Initial assessment: 1 week
|
||||||
- **Fix Timeline**: Varies based on severity
|
- Critical fixes: 7 days
|
||||||
- Critical: Within 7 days
|
- High priority: 30 days
|
||||||
- High: Within 14 days
|
|
||||||
- Medium: Within 30 days
|
|
||||||
- Low: Next release cycle
|
|
||||||
|
|
||||||
### Disclosure Policy
|
## Security Best Practices
|
||||||
|
|
||||||
We follow responsible disclosure practices:
|
- Test only in authorized environments
|
||||||
|
- Run with minimum privileges
|
||||||
|
- Keep Ghost updated
|
||||||
|
- Sanitize logs before sharing
|
||||||
|
- Follow responsible disclosure
|
||||||
|
|
||||||
1. Security researcher reports vulnerability privately
|
## Known Limitations
|
||||||
2. We acknowledge receipt and begin investigation
|
|
||||||
3. We develop and test a fix
|
|
||||||
4. We prepare a security advisory
|
|
||||||
5. We release the fix and publish the advisory
|
|
||||||
6. Public disclosure after 90 days (or sooner if fix is available)
|
|
||||||
|
|
||||||
### Security Best Practices for Users
|
- Advanced malware may evade detection
|
||||||
|
- Kernel rootkits not detectable
|
||||||
|
- Platform-specific limitations
|
||||||
|
- Performance overhead on production systems
|
||||||
|
|
||||||
1. **Keep Ghost Updated**: Always use the latest version
|
Thank you for helping keep Ghost secure!
|
||||||
2. **Run with Minimal Privileges**: Don't run as Administrator unless necessary
|
|
||||||
3. **Validate Detection Results**: Ghost is a tool to assist analysis, not replace human judgment
|
|
||||||
4. **Secure Your Environment**: Ensure your analysis environment is properly isolated
|
|
||||||
|
|
||||||
### Known Security Considerations
|
|
||||||
|
|
||||||
1. **Memory Access**: Ghost requires elevated privileges to read process memory
|
|
||||||
2. **False Positives**: Detection engines may flag legitimate software
|
|
||||||
3. **Evasion**: Advanced malware may evade detection techniques
|
|
||||||
4. **Performance Impact**: Intensive scanning may affect system performance
|
|
||||||
|
|
||||||
### Security Features
|
|
||||||
|
|
||||||
- Memory-safe Rust implementation
|
|
||||||
- Input validation on all API boundaries
|
|
||||||
- Minimal attack surface design
|
|
||||||
- No network communication by default
|
|
||||||
- Comprehensive error handling
|
|
||||||
|
|
||||||
### Vulnerability Categories We're Interested In
|
|
||||||
|
|
||||||
**High Priority:**
|
|
||||||
|
|
||||||
- Memory safety violations
|
|
||||||
- Privilege escalation
|
|
||||||
- Code injection vulnerabilities
|
|
||||||
- Authentication bypass
|
|
||||||
- Sensitive data exposure
|
|
||||||
|
|
||||||
**Medium Priority:**
|
|
||||||
|
|
||||||
- Denial of service
|
|
||||||
- Information disclosure
|
|
||||||
- Logic flaws in detection algorithms
|
|
||||||
|
|
||||||
**Out of Scope:**
|
|
||||||
|
|
||||||
- Issues requiring physical access
|
|
||||||
- Social engineering attacks
|
|
||||||
- Third-party dependency vulnerabilities (unless exploitable through Ghost)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*Last updated: November 2025*
|
|
||||||
|
|||||||
Reference in New Issue
Block a user